From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id B31D9C6FA82 for ; Tue, 20 Sep 2022 00:47:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229602AbiITArO (ORCPT ); Mon, 19 Sep 2022 20:47:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50378 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229471AbiITArN (ORCPT ); Mon, 19 Sep 2022 20:47:13 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8C793476DB; Mon, 19 Sep 2022 17:47:12 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 100FBB81D41; Tue, 20 Sep 2022 00:47:11 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A3727C43142; Tue, 20 Sep 2022 00:47:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1663634829; bh=xP/qeVjxP9D7WAylNWjp5M1UVyW3ePRF51jsVQNhb6M=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=QQPHDA/rmZeGmg4vRVdL3NsKvKD3TaRcKVna3BdM9JeoVwJ6pke7eJjtIOObQLXBA dE5ROwWuXKUWG7GOnz04IIjOyMupp2IFSCY1Qan2zdiKbx2FGE9jerCSbvTDFu1xM8 O1kHOBLOteHXQZUqVd+UVtNVlh7OPQ1/moZMl0j6u2oIX9zbuCmnPdBzr8u/ywNvC8 85vzoTPsiDHQR1yy5Grq5sc9gXaMGfiQxx76yRqq4p/6QsRSFAA8K43CeYIpmdXQgN /pTP6BTHaYfm+DQjfDIFPgU6bOYKu37RyUbGQB1BueeYM1IuKOo17bnnCuocyvX5n9 fEDuwptUghy0g== Received: by mail-oa1-f50.google.com with SMTP id 586e51a60fabf-12803ac8113so1956277fac.8; Mon, 19 Sep 2022 17:47:09 -0700 (PDT) X-Gm-Message-State: ACrzQf3L5i5enHOBUA3DhIELzM0JkVNSpfQa8zQH+LL+mbO2c4IKQR1O xvEt+KcGkOkHcQPAxBzWOS4ErKn2fBcRqzhXeh8= X-Google-Smtp-Source: AMsMyM6SzMrhnEnurC88o5RK3FSySIO2geSRWmUq+5Zhq2V6q1TFt+qBpX29RTKP8TzwzNGJDD/k5Zn/L7dXo+SaQoU= X-Received: by 2002:a05:6870:a78e:b0:12b:542b:e5b2 with SMTP id x14-20020a056870a78e00b0012b542be5b2mr557154oao.112.1663634828649; Mon, 19 Sep 2022 17:47:08 -0700 (PDT) MIME-Version: 1.0 References: <20220908022506.1275799-1-guoren@kernel.org> <20220908022506.1275799-9-guoren@kernel.org> <4babce64-e96d-454c-aa35-243b3f2dc315@www.fastmail.com> <8817af55-de0d-4e8f-a41b-25d01d5fa968@www.fastmail.com> In-Reply-To: From: Guo Ren Date: Tue, 20 Sep 2022 08:46:55 +0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH V4 8/8] riscv: Add config of thread stack size To: Arnd Bergmann Cc: Palmer Dabbelt , Thomas Gleixner , Peter Zijlstra , Andy Lutomirski , "Conor.Dooley" , =?UTF-8?Q?Heiko_St=C3=BCbner?= , Jisheng Zhang , lazyparser@gmail.com, falcon@tinylab.org, Huacai Chen , Anup Patel , Atish Patra , Palmer Dabbelt , Paul Walmsley , Sebastian Andrzej Siewior , Linux-Arch , linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org, Guo Ren , Andreas Schwab Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-arch@vger.kernel.org On Mon, Sep 19, 2022 at 4:35 PM Guo Ren wrote: > > On Sun, Sep 11, 2022 at 12:07 AM Arnd Bergmann wrote: > > > > On Sat, Sep 10, 2022, at 2:52 PM, Guo Ren wrote: > > > On Thu, Sep 8, 2022 at 3:37 PM Arnd Bergmann wrote: > > >> On Thu, Sep 8, 2022, at 4:25 AM, guoren@kernel.org wrote: > > >> > From: Guo Ren > > >> - 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. > > > I don't want this config to depend on VMAP_STACK. Some D1 chips would > > > run with an 8K stack size and !VMAP_STACK. > > > > That sounds like a really bad idea, why would you want to risk > > using such a small stack without CONFIG_VMAP_STACK? > > > > Are you worried about increased memory usage or something else? > > > > > /* thread information allocation */ > > > -#ifdef CONFIG_64BIT > > > -#define THREAD_SIZE_ORDER (2 + KASAN_STACK_ORDER) > > > -#else > > > -#define THREAD_SIZE_ORDER (1 + KASAN_STACK_ORDER) > > > -#endif > > > +#define THREAD_SIZE_ORDER CONFIG_THREAD_SIZE_ORDER > > > #define THREAD_SIZE (PAGE_SIZE << THREAD_SIZE_ORDER) > > > > This doesn't actually allow additional THREAD_SIZE values, as you > > still round up to the nearest power of two. > > > > I think all the non-arch code can deal with non-power-of-2 > > sizes, so you'd just need > > > > #define THREAD_SIZE round_up(CONFIG_THREAD_SIZE, PAGE_SIZE) > > > > and fix up the risc-v specific code to do the right thing > > as well. I now see that THREAD_SIZE_ORDER is not actually > > used anywhere with CONFIG_VMAP_STACK, so I suppose that > > definition can be skipped, but you still need a THREAD_ALIGN > > definition that is a power of two and at least a page larger > > than THREAD_SIZE. > Sorry, I missed this part. I would RESEND v5 Hi Arnd, How about this one: (only THREAD_SIZE, no THREAD_ORDER&SHIFT.) commit 447cddede7898c35a9a3b8ab3d7bdb7b0de0714d (HEAD) Author: Guo Ren Date: Mon Sep 5 22:53:06 2022 -0400 riscv: Add config of thread stack size 0cac21b02ba5 ("riscv: 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 Signed-off-by: Guo Ren Cc: Andreas Schwab diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index dfe600f3526c..8def456f328c 100644 --- a/arch/riscv/Kconfig +++ b/arch/riscv/Kconfig @@ -442,6 +442,16 @@ 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 + int "Kernel stack size (in bytes)" if EXPERT + range 4096 65536 + default 8192 if 32BIT && !KASAN + default 32768 if 64BIT && KASAN + default 16384 + help + Specify the Pages of thread stack size (from 4KB to 64KB), which also + affects irq stack size, which is equal to thread stack size. + endmenu # "Platform type" menu "Kernel features" diff --git a/arch/riscv/include/asm/thread_info.h b/arch/riscv/include/asm/thread_info.h index 043da8ccc7e6..181fdfbd5e99 100644 --- a/arch/riscv/include/asm/thread_info.h +++ b/arch/riscv/include/asm/thread_info.h @@ -11,24 +11,12 @@ #include #include -#ifdef CONFIG_KASAN -#define KASAN_STACK_ORDER 1 -#else -#define KASAN_STACK_ORDER 0 -#endif - /* thread information allocation */ -#ifdef CONFIG_64BIT -#define THREAD_SIZE_ORDER (2 + KASAN_STACK_ORDER) -#else -#define THREAD_SIZE_ORDER (1 + KASAN_STACK_ORDER) -#endif -#define THREAD_SIZE (PAGE_SIZE << THREAD_SIZE_ORDER) +#define THREAD_SIZE CONFIG_THREAD_SIZE /* * By aligning VMAP'd stacks to 2 * THREAD_SIZE, we can detect overflow by - * checking sp & (1 << THREAD_SHIFT), which we can do cheaply in the entry - * assembly. + * checking sp & THREAD_SIZE, which we can do cheaply in the entry assembly. */ #ifdef CONFIG_VMAP_STACK #define THREAD_ALIGN (2 * THREAD_SIZE) @@ -36,7 +24,6 @@ #define THREAD_ALIGN THREAD_SIZE #endif -#define THREAD_SHIFT (PAGE_SHIFT + THREAD_SIZE_ORDER) #define OVERFLOW_STACK_SIZE SZ_4K #define SHADOW_OVERFLOW_STACK_SIZE (1024) diff --git a/arch/riscv/kernel/entry.S b/arch/riscv/kernel/entry.S index 426529b84db0..1e35fb3bdae5 100644 --- a/arch/riscv/kernel/entry.S +++ b/arch/riscv/kernel/entry.S @@ -29,8 +29,8 @@ _restore_kernel_tpsp: #ifdef CONFIG_VMAP_STACK addi sp, sp, -(PT_SIZE_ON_STACK) - srli sp, sp, THREAD_SHIFT - andi sp, sp, 0x1 + srli sp, sp, PAGE_SHIFT + andi sp, sp, (THREAD_SIZE >> PAGE_SHIFT) bnez sp, handle_kernel_stack_overflow REG_L sp, TASK_TI_KERNEL_SP(tp) #endif > > > > > Arnd > > > > -- > Best Regards > Guo Ren -- Best Regards Guo Ren