Re: [PATCH] mm/damon/core: reduce kernel stack usage

[Arnd Bergmann]

On Thu, Jun 11, 2026, at 20:50, David Laight wrote:
> On Thu, 11 Jun 2026 14:56:57 +0200
> Arnd Bergmann <arnd@xxxxxxxxxx> wrote:
>
>> From: Arnd Bergmann <arnd@xxxxxxxx>
>> 
>> The main thread function has recently grown to the point of
>> exceeding stack frame size warning limits in some configurations.
>> This is what I hit on s390 with clang and CONFIG_KASAN:
>> 
>> mm/damon/core.c:3440:31: error: stack frame size (1352) exceeds limit (1280) in 'kdamond_fn' [-Werror,-Wframe-larger-than]
>>  3440 | static int kdamond_fn(struct damon_ctx *ctx)
>> 
>> The largest stack usage here is inside of the kdamond_tune_intervals(),
>> so by marking that one as noinline_for_stack, the functions individually
>> stay below the warning limit, though kdamond_fn() itself still uses
>> hundreds of kilobytes for some reason.
>
> Does that actually reduce the stack use if the functions are called?
> Or just stop the compiler bleating and running the code is still likely
> to overflow the stack.

The one code path that was identified by the compiler does not
improve, as the sum of the caller and the callee is still the
same. As far as I can tell, the stack usage in gcc is similar
in this code path, but it doesn't warn because the normal
inliner does not combine these two.

It does help in other leaf functions called by kdamond_fn() that
now don't have the kdamond_tune_intervals() variables on the
stack on top of their own ones, so in any other extern function
called indirectly by kdamond_fn, more stack space is available.

> I did that many many years ago for an embedded system (no indirect calls),
> the outcome was that we didn't have enough memory to allow for the worst
> case stack use!
> The deep places were all (the equivalent of) printk() in pretty
> impossible error paths.

Yes, that is a well known problem: it is very easy to construct
call chains that are possible in the kernel that go way beyond
any sensible size limit. Importantly, any GFP_KERNEL allocation
can end up in the file system reclaim path.

The -Wframe-larger-than= warnings are just one way to make
this less likely to happen.

     Arnd