From: David Laight <david.laight.linux@gmail.com>
To: Arnd Bergmann <arnd@kernel.org>
Cc: SeongJae Park <sj@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Nathan Chancellor <nathan@kernel.org>,
Arnd Bergmann <arnd@arndb.de>,
Nick Desaulniers <nick.desaulniers+lkml@gmail.com>,
Bill Wendling <morbo@google.com>,
Justin Stitt <justinstitt@google.com>,
Ravi Jonnalagadda <ravis.opensrc@gmail.com>,
Quanmin Yan <yanquanmin1@huawei.com>,
damon@lists.linux.dev, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, llvm@lists.linux.dev
Subject: Re: [PATCH] mm/damon/core: reduce kernel stack usage
Date: Thu, 11 Jun 2026 19:50:37 +0100 [thread overview]
Message-ID: <20260611195037.1adec04d@pumpkin> (raw)
In-Reply-To: <20260611125704.3386176-1-arnd@kernel.org>
On Thu, 11 Jun 2026 14:56:57 +0200
Arnd Bergmann <arnd@kernel.org> wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> 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.
I keep thinking it should be possible to get (say) objtool to output
the stack offsets of every call.
With (I think it is) fine-ibt the hashes can be used so separate all the
indirect calls (although you might need a 'salt' to separate the different
'void (*)(void *)' functions - that probably ought to be done anyway).
Then it is a SMOP to generate a maximal stack depth for each function and
to detect the recursive loops.
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.
-- David
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> mm/damon/core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/damon/core.c b/mm/damon/core.c
> index 265d51ade25b..69f38c48ac08 100644
> --- a/mm/damon/core.c
> +++ b/mm/damon/core.c
> @@ -2002,7 +2002,7 @@ static unsigned long damon_get_intervals_adaptation_bp(struct damon_ctx *c)
> return adaptation_bp;
> }
>
> -static void kdamond_tune_intervals(struct damon_ctx *c)
> +static noinline_for_stack void kdamond_tune_intervals(struct damon_ctx *c)
> {
> unsigned long adaptation_bp;
> struct damon_attrs new_attrs;
prev parent reply other threads:[~2026-06-11 18:50 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-11 12:56 [PATCH] mm/damon/core: reduce kernel stack usage Arnd Bergmann
2026-06-11 13:56 ` SeongJae Park
2026-06-11 18:50 ` David Laight [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260611195037.1adec04d@pumpkin \
--to=david.laight.linux@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=arnd@kernel.org \
--cc=damon@lists.linux.dev \
--cc=justinstitt@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=llvm@lists.linux.dev \
--cc=morbo@google.com \
--cc=nathan@kernel.org \
--cc=nick.desaulniers+lkml@gmail.com \
--cc=ravis.opensrc@gmail.com \
--cc=sj@kernel.org \
--cc=yanquanmin1@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.