From: "Arnd Bergmann" <arnd@arndb.de>
To: guoren@kernel.org, palmer@rivosinc.com,
"Thomas Gleixner" <tglx@linutronix.de>,
"Peter Zijlstra" <peterz@infradead.org>,
luto@kernel.org, conor.dooley@microchip.com, heiko@sntech.de,
jszhang@kernel.org, lazyparser@gmail.com, falcon@tinylab.org,
"Huacai Chen" <chenhuacai@kernel.org>,
apatel@ventanamicro.com, atishp@atishpatra.org,
"Palmer Dabbelt" <palmer@dabbelt.com>,
"Paul Walmsley" <paul.walmsley@sifive.com>,
bigeasy@linutronix.de
Cc: Linux-Arch <linux-arch@vger.kernel.org>,
linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org,
"Guo Ren" <guoren@linux.alibaba.com>,
"Andreas Schwab" <schwab@suse.de>
Subject: Re: [PATCH V4 8/8] riscv: Add config of thread stack size
Date: Thu, 08 Sep 2022 09:35:48 +0200 [thread overview]
Message-ID: <4babce64-e96d-454c-aa35-243b3f2dc315@www.fastmail.com> (raw)
In-Reply-To: <20220908022506.1275799-9-guoren@kernel.org>
On Thu, Sep 8, 2022, at 4:25 AM, guoren@kernel.org wrote:
> From: Guo Ren <guoren@linux.alibaba.com>
>
> 0cac21b02ba5 ("risc v: use 16KB kernel stack on 64-bit") increase the
> thread size mandatory, but some scenarios, such as D1 with a small
> memory footprint, would suffer from that. After independent irq stack
> support, let's give users a choice to determine their custom stack size.
>
> Signed-off-by: Guo Ren <guoren@linux.alibaba.com>
> Signed-off-by: Guo Ren <guoren@kernel.org>
> Cc: Andreas Schwab <schwab@suse.de>
> ---
> arch/riscv/Kconfig | 9 +++++++++
> arch/riscv/include/asm/thread_info.h | 4 ++--
> 2 files changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index da548ed7d107..e436b5793ab6 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -442,6 +442,15 @@ config IRQ_STACKS
> Add independent irq & softirq stacks for percpu to prevent kernel stack
> overflows. We may save some memory footprint by disabling IRQ_STACKS.
>
> +config THREAD_SIZE_ORDER
> + int "Pages of thread stack size (as a power of 2)"
> + range 1 4
> + default "1" if 32BIT
> + default "2" if 64BIT
> + help
> + Specify the Pages of thread stack size (from 8KB to 64KB), which also
> + affects irq stack size, which is equal to thread stack size.
I would suggest hiding this under 'depends on EXPERT', no
need to bother normal users with that question because the
defaults are probably what everyone should use unless they are
extremely limited.
> #ifdef CONFIG_64BIT
> -#define THREAD_SIZE_ORDER (2 + KASAN_STACK_ORDER)
> +#define THREAD_SIZE_ORDER (CONFIG_THREAD_SIZE_ORDER + KASAN_STACK_ORDER)
> #else
> -#define THREAD_SIZE_ORDER (1 + KASAN_STACK_ORDER)
> +#define THREAD_SIZE_ORDER (CONFIG_THREAD_SIZE_ORDER + KASAN_STACK_ORDER)
> #endif
The two sides of the #ifdef are now the same, so you no longer
need both. You could also consider expressing the KASAN_STACK_ORDER
bit in Kconfig logic for consistency, and put those into the
defaults as well. Unless you actually use CONFIG_KASAN_STACK,
the stack requirements of KASAN are not too bad, so that way one
could decide to still use a smaller stack even with KASAN.
If you want to make the setting really useful, you can add two
more ideas:
- When VMAP_STACK is set, make it possible to select non-power-of-two
stack sizes. Most importantly, 12KB should be a really interesting
choice as 8KB is probably still not enough for many 64-bit workloads,
but 16KB is often more than what you need. You probably don't
want to allow 64BIT/8KB without VMAP_STACK anyway since that just
makes it really hard to debug, so hiding the option when VMAP_STACK
is disabled may also be a good idea.
- For testing purposes, you can even allow byte-exact stack sizes
that allow finding out what the actual minimum is by adding a
fixed offset during kernel entry. See add_random_kstack_offset()
for how to adjust the stack.
With all those ideas added in, the Kconfig logic would be
something like (assuming you can use
config THREAD_SIZE
int "Kernel stack size (in bytes)" if VMAP_STACK && EXPERT
range 4096 65536
default 8192 if 32BIT && !KASAN
default 32768 if 64BIT && KASAN
default 16384
config THREAD_SIZE_ORDER
int
default 0 if THREAD_SIZE = 4096
default 1 if THREAD_SIZE <= 8192
default 2 if THREAD_SIZE <= 16384
default 3 if THREAD_SIZE <= 32768
default 4
Arnd
next prev parent reply other threads:[~2022-09-08 7:37 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-08 2:24 [PATCH V4 0/9] riscv: Add GENERIC_ENTRY, irq stack support guoren
2022-09-08 2:24 ` [PATCH V4 1/8] riscv: elf_kexec: Fixup compile warning guoren
2022-09-08 2:25 ` [PATCH V4 2/8] riscv: compat_syscall_table: " guoren
2022-09-08 2:25 ` [PATCH V4 3/8] riscv: ptrace: Remove duplicate operation guoren
2022-09-08 2:25 ` [PATCH V4 4/8] riscv: traps: Add noinstr to prevent instrumentation inserted guoren
2022-09-08 7:33 ` Peter Zijlstra
2022-09-10 9:17 ` Guo Ren
2022-09-10 12:46 ` Guo Ren
2022-09-11 15:09 ` Peter Zijlstra
2022-09-11 16:20 ` Guo Ren
2022-09-08 2:25 ` [PATCH V4 5/8] riscv: convert to generic entry guoren
2022-09-15 13:50 ` Yipeng Zou
2022-09-08 2:25 ` [PATCH V4 6/8] riscv: Support HAVE_IRQ_EXIT_ON_IRQ_STACK guoren
2022-09-08 16:08 ` Sebastian Andrzej Siewior
2022-09-09 7:30 ` David Laight
2022-09-11 1:13 ` Guo Ren
2022-09-08 2:25 ` [PATCH V4 7/8] riscv: Support HAVE_SOFTIRQ_ON_OWN_STACK guoren
2022-09-08 16:01 ` Sebastian Andrzej Siewior
2022-09-18 15:42 ` Guo Ren
2022-09-08 2:25 ` [PATCH V4 8/8] riscv: Add config of thread stack size guoren
2022-09-08 7:35 ` Arnd Bergmann [this message]
2022-09-10 12:52 ` Guo Ren
2022-09-10 16:06 ` Arnd Bergmann
2022-09-10 23:35 ` Guo Ren
2022-09-11 18:39 ` Arnd Bergmann
2022-09-12 4:14 ` Guo Ren
2022-09-12 8:23 ` Arnd Bergmann
2022-09-19 8:38 ` Guo Ren
2022-09-19 8:35 ` Guo Ren
2022-09-20 0:46 ` Guo Ren
2022-09-20 7:15 ` Arnd Bergmann
2022-09-21 6:11 ` Guo Ren
2022-09-20 7:17 ` Arnd Bergmann
2022-09-21 6:13 ` Guo Ren
2022-09-21 8:23 ` Guo Ren
2022-09-21 10:31 ` Guo Ren
2022-09-21 10:46 ` Guo Ren
2022-09-22 5:55 ` Arnd Bergmann
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=4babce64-e96d-454c-aa35-243b3f2dc315@www.fastmail.com \
--to=arnd@arndb.de \
--cc=apatel@ventanamicro.com \
--cc=atishp@atishpatra.org \
--cc=bigeasy@linutronix.de \
--cc=chenhuacai@kernel.org \
--cc=conor.dooley@microchip.com \
--cc=falcon@tinylab.org \
--cc=guoren@kernel.org \
--cc=guoren@linux.alibaba.com \
--cc=heiko@sntech.de \
--cc=jszhang@kernel.org \
--cc=lazyparser@gmail.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=luto@kernel.org \
--cc=palmer@dabbelt.com \
--cc=palmer@rivosinc.com \
--cc=paul.walmsley@sifive.com \
--cc=peterz@infradead.org \
--cc=schwab@suse.de \
--cc=tglx@linutronix.de \
/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 NNTP newsgroup(s).