From: Matthew Wilcox <willy@infradead.org>
To: Brian Cain <bcain@quicinc.com>
Cc: Nathan Chancellor <nathan@kernel.org>,
kernel test robot <lkp@intel.com>,
"llvm@lists.linux.dev" <llvm@lists.linux.dev>,
"kbuild-all@lists.01.org" <kbuild-all@lists.01.org>,
Linux Memory Management List <linux-mm@kvack.org>,
"linux-hexagon@vger.kernel.org" <linux-hexagon@vger.kernel.org>,
Sid Manning <sidneym@quicinc.com>
Subject: Re: [linux-next:master 9995/11651] fs/buffer.c:2254:5: warning: stack frame size (2144) exceeds limit (1024) in 'block_read_full_folio'
Date: Tue, 17 May 2022 05:48:30 +0100 [thread overview]
Message-ID: <YoMpHlVdH+HCMhUj@casper.infradead.org> (raw)
In-Reply-To: <SN6PR02MB4205A0695B4B2543A9B981FCB8CE9@SN6PR02MB4205.namprd02.prod.outlook.com>
On Tue, May 17, 2022 at 04:16:45AM +0000, Brian Cain wrote:
> > -----Original Message-----
> > From: Nathan Chancellor <nathan@kernel.org>
> ...
> > As a side note... Brian, is there any reason for 256K pages to exist for
> > Hexagon? This has been an option since Hexagon's introduction but is it
> > actually used? 4K pages is the default and the help text says "use with
> > caution". Perhaps the choice should be turned off altogether for
> > CONFIG_COMPILE_TEST so that we cannot select this configuration and
> > bother developers with these reports.
>
> It's not the most commonly used page size, yeah. Ok, we will disable it for CONFIG_COMPILE_TEST.
Maybe the stack size limit could be raised for 256KB page size?
Presumably the minimum stack size is 256KB, so it's not a problem for an
individual function to consume 16KB of stack space?
prev parent reply other threads:[~2022-05-17 4:48 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <202205150051.3RzuooAG-lkp@intel.com>
[not found] ` <Yn/YsTpOh898B30l@casper.infradead.org>
2022-05-14 21:57 ` [linux-next:master 9995/11651] fs/buffer.c:2254:5: warning: stack frame size (2144) exceeds limit (1024) in 'block_read_full_folio' Nathan Chancellor
2022-05-15 0:30 ` Matthew Wilcox
2022-05-16 10:09 ` [kbuild-all] " Chen, Rong A
2022-05-17 4:16 ` Brian Cain
2022-05-17 4:48 ` Matthew Wilcox [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=YoMpHlVdH+HCMhUj@casper.infradead.org \
--to=willy@infradead.org \
--cc=bcain@quicinc.com \
--cc=kbuild-all@lists.01.org \
--cc=linux-hexagon@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lkp@intel.com \
--cc=llvm@lists.linux.dev \
--cc=nathan@kernel.org \
--cc=sidneym@quicinc.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).