From: Randy Dunlap <rdunlap@infradead.org> To: Libo Chen <libo.chen@oracle.com>, Arnd Bergmann <arnd@arndb.de> Cc: gregkh <gregkh@linuxfoundation.org>, Masahiro Yamada <masahiroy@kernel.org>, Thomas Gleixner <tglx@linutronix.de>, Peter Zijlstra <peterz@infradead.org>, Ingo Molnar <mingo@kernel.org>, Vlastimil Babka <vbabka@suse.cz>, Andrew Morton <akpm@linux-foundation.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>, Linux ARM <linux-arm-kernel@lists.infradead.org>, linux-arch <linux-arch@vger.kernel.org> Subject: Re: [PATCH RESEND 1/1] lib/Kconfig: remove DEBUG_PER_CPU_MAPS dependency for CPUMASK_OFFSTACK Date: Wed, 13 Apr 2022 18:20:58 -0700 [thread overview] Message-ID: <98d190a3-b3f3-0fa5-be0f-8d602ffe7aea@infradead.org> (raw) In-Reply-To: <ce420ed3-4a36-122f-460d-8cccd0310033@oracle.com> Hi, On 4/13/22 14:50, Libo Chen wrote: > > > On 4/13/22 13:52, Arnd Bergmann wrote: >> On Wed, Apr 13, 2022 at 9:28 PM Libo Chen <libo.chen@oracle.com> wrote: >>> On 4/13/22 08:41, Randy Dunlap wrote: >>>> On 4/12/22 23:56, Libo Chen wrote: >>>>>> --- a/lib/Kconfig >>>>>> +++ b/lib/Kconfig >>>>>> @@ -511,7 +511,8 @@ config CHECK_SIGNATURE >>>>>> bool >>>>>> config CPUMASK_OFFSTACK >>>>>> - bool "Force CPU masks off stack" if DEBUG_PER_CPU_MAPS >>>>>> + bool "Force CPU masks off stack" >>>>>> + depends on DEBUG_PER_CPU_MAPS >>>>> This forces every arch to enable DEBUG_PER_CPU_MAPS if they want to enable CPUMASK_OFFSTACK, it's even stronger than "if". My whole argument is CPUMASK_OFFSTACK should be enable/disabled independent of DEBUG_PER_CPU_MASK >>>>>> help >>>>>> Use dynamic allocation for cpumask_var_t, instead of putting >>>>>> them on the stack. This is a bit more expensive, but avoids >>>>>> >>>>>> >>>>>> As I said earlier, the "if" on the "bool" line just controls the prompt message. >>>>>> This patch make CPUMASK_OFFSTACK require DEBUG_PER_CPU_MAPS -- which might be overkill. >>>>>> >>>>> Okay I understand now "if" on the "boot" is not a dependency and it only controls the prompt message, then the question is why we cannot enable CPUMASK_OFFSTACK without DEBUG_PER_CPU_MAPS if it only controls prompt message? Is it not the behavior we expect? >>>> Yes, it is. I don't know that the problem is... >>> Masahiro explained that CPUMASK_OFFSTACK can only be configured by >>> options not users if DEBUG_PER_CPU_MASK is not enabled. This doesn't >>> seem to be what we want. >> I think the correct way to do it is to follow x86 and powerpc, and tying >> CPUMASK_OFFSTACK to "large" values of CONFIG_NR_CPUS. Sure. Just FTR, I was just trying to see if an arch (arm64) would build OK or not when CPUMASK_OFFSTACK was enabled. and it does. My patch wasn't meant to have a very long life. >> For smaller values of NR_CPUS, the onstack masks are obviously >> cheaper, we just need to decide what the cut-off point is. > I agree. It appears enabling CPUMASK_OFFSTACK breaks kernel builds on some architectures such as parisc and nios2 as reported by kernel test robot. Maybe it makes sense to use DEBUG_PER_CPU_MAPS as some kind of guard on CPUMASK_OFFSTACK. >> In x86, the onstack masks can be selected for normal SMP builds with >> up to 512 CPUs, while CONFIG_MAXSMP=y raises the limit to 8192 >> CPUs while selecting CPUMASK_OFFSTACK. >> PowerPC does it the other way round, selecting CPUMASK_OFFSTACK >> implicitly whenever NR_CPUS is set to 8192 or more. >> >> I think we can easily do the same as powerpc on arm64. With the > I am leaning more towards x86's way because even NR_CPUS=160 is too expensive for 4-core arm64 VMs according to apachebench. I highly doubt that there is a good cut-off point to make everybody happy (or not unhappy). >> ApacheBench test you cite in the patch description, what is the >> value of NR_CPUS at which you start seeing a noticeable >> benefit for offstack masks? Can you do the same test for >> NR_CPUS=1024 or 2048? > As mentioned above, a good cut-off point moves depends on the actual number of CPUs. But yeah I can do the same test for 1024 or even smaller NR_CPUs values on the same 64-core arm64 VM setup. -- ~Randy
WARNING: multiple messages have this Message-ID (diff)
From: Randy Dunlap <rdunlap@infradead.org> To: Libo Chen <libo.chen@oracle.com>, Arnd Bergmann <arnd@arndb.de> Cc: gregkh <gregkh@linuxfoundation.org>, Masahiro Yamada <masahiroy@kernel.org>, Thomas Gleixner <tglx@linutronix.de>, Peter Zijlstra <peterz@infradead.org>, Ingo Molnar <mingo@kernel.org>, Vlastimil Babka <vbabka@suse.cz>, Andrew Morton <akpm@linux-foundation.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>, Linux ARM <linux-arm-kernel@lists.infradead.org>, linux-arch <linux-arch@vger.kernel.org> Subject: Re: [PATCH RESEND 1/1] lib/Kconfig: remove DEBUG_PER_CPU_MAPS dependency for CPUMASK_OFFSTACK Date: Wed, 13 Apr 2022 18:20:58 -0700 [thread overview] Message-ID: <98d190a3-b3f3-0fa5-be0f-8d602ffe7aea@infradead.org> (raw) In-Reply-To: <ce420ed3-4a36-122f-460d-8cccd0310033@oracle.com> Hi, On 4/13/22 14:50, Libo Chen wrote: > > > On 4/13/22 13:52, Arnd Bergmann wrote: >> On Wed, Apr 13, 2022 at 9:28 PM Libo Chen <libo.chen@oracle.com> wrote: >>> On 4/13/22 08:41, Randy Dunlap wrote: >>>> On 4/12/22 23:56, Libo Chen wrote: >>>>>> --- a/lib/Kconfig >>>>>> +++ b/lib/Kconfig >>>>>> @@ -511,7 +511,8 @@ config CHECK_SIGNATURE >>>>>> bool >>>>>> config CPUMASK_OFFSTACK >>>>>> - bool "Force CPU masks off stack" if DEBUG_PER_CPU_MAPS >>>>>> + bool "Force CPU masks off stack" >>>>>> + depends on DEBUG_PER_CPU_MAPS >>>>> This forces every arch to enable DEBUG_PER_CPU_MAPS if they want to enable CPUMASK_OFFSTACK, it's even stronger than "if". My whole argument is CPUMASK_OFFSTACK should be enable/disabled independent of DEBUG_PER_CPU_MASK >>>>>> help >>>>>> Use dynamic allocation for cpumask_var_t, instead of putting >>>>>> them on the stack. This is a bit more expensive, but avoids >>>>>> >>>>>> >>>>>> As I said earlier, the "if" on the "bool" line just controls the prompt message. >>>>>> This patch make CPUMASK_OFFSTACK require DEBUG_PER_CPU_MAPS -- which might be overkill. >>>>>> >>>>> Okay I understand now "if" on the "boot" is not a dependency and it only controls the prompt message, then the question is why we cannot enable CPUMASK_OFFSTACK without DEBUG_PER_CPU_MAPS if it only controls prompt message? Is it not the behavior we expect? >>>> Yes, it is. I don't know that the problem is... >>> Masahiro explained that CPUMASK_OFFSTACK can only be configured by >>> options not users if DEBUG_PER_CPU_MASK is not enabled. This doesn't >>> seem to be what we want. >> I think the correct way to do it is to follow x86 and powerpc, and tying >> CPUMASK_OFFSTACK to "large" values of CONFIG_NR_CPUS. Sure. Just FTR, I was just trying to see if an arch (arm64) would build OK or not when CPUMASK_OFFSTACK was enabled. and it does. My patch wasn't meant to have a very long life. >> For smaller values of NR_CPUS, the onstack masks are obviously >> cheaper, we just need to decide what the cut-off point is. > I agree. It appears enabling CPUMASK_OFFSTACK breaks kernel builds on some architectures such as parisc and nios2 as reported by kernel test robot. Maybe it makes sense to use DEBUG_PER_CPU_MAPS as some kind of guard on CPUMASK_OFFSTACK. >> In x86, the onstack masks can be selected for normal SMP builds with >> up to 512 CPUs, while CONFIG_MAXSMP=y raises the limit to 8192 >> CPUs while selecting CPUMASK_OFFSTACK. >> PowerPC does it the other way round, selecting CPUMASK_OFFSTACK >> implicitly whenever NR_CPUS is set to 8192 or more. >> >> I think we can easily do the same as powerpc on arm64. With the > I am leaning more towards x86's way because even NR_CPUS=160 is too expensive for 4-core arm64 VMs according to apachebench. I highly doubt that there is a good cut-off point to make everybody happy (or not unhappy). >> ApacheBench test you cite in the patch description, what is the >> value of NR_CPUS at which you start seeing a noticeable >> benefit for offstack masks? Can you do the same test for >> NR_CPUS=1024 or 2048? > As mentioned above, a good cut-off point moves depends on the actual number of CPUs. But yeah I can do the same test for 1024 or even smaller NR_CPUs values on the same 64-core arm64 VM setup. -- ~Randy _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-04-14 1:21 UTC|newest] Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-04-12 23:15 [PATCH RESEND 0/1] lib/Kconfig: remove DEBUG_PER_CPU_MAPS dependency for CPUMASK_OFFSTACK Libo Chen 2022-04-12 23:15 ` Libo Chen 2022-04-12 23:15 ` [PATCH RESEND 1/1] " Libo Chen 2022-04-12 23:15 ` Libo Chen 2022-04-13 0:18 ` Randy Dunlap 2022-04-13 0:18 ` Randy Dunlap 2022-04-13 1:35 ` Libo Chen 2022-04-13 1:35 ` Libo Chen 2022-04-13 2:13 ` Randy Dunlap 2022-04-13 2:13 ` Randy Dunlap 2022-04-13 2:34 ` Libo Chen 2022-04-13 2:34 ` Libo Chen 2022-04-13 5:54 ` Randy Dunlap 2022-04-13 5:54 ` Randy Dunlap 2022-04-13 6:56 ` Libo Chen 2022-04-13 6:56 ` Libo Chen 2022-04-13 8:37 ` Masahiro Yamada 2022-04-13 8:37 ` Masahiro Yamada 2022-04-13 15:41 ` Randy Dunlap 2022-04-13 15:41 ` Randy Dunlap 2022-04-13 19:28 ` Libo Chen 2022-04-13 19:28 ` Libo Chen 2022-04-13 20:52 ` Arnd Bergmann 2022-04-13 20:52 ` Arnd Bergmann 2022-04-13 21:50 ` Libo Chen 2022-04-13 21:50 ` Libo Chen 2022-04-14 1:20 ` Randy Dunlap [this message] 2022-04-14 1:20 ` Randy Dunlap 2022-04-14 11:41 ` Arnd Bergmann 2022-04-14 11:41 ` Arnd Bergmann 2022-04-14 18:01 ` Libo Chen 2022-04-14 18:01 ` Libo Chen 2022-04-13 13:11 ` kernel test robot 2022-04-13 13:11 ` kernel test robot 2022-04-13 14:33 ` kernel test robot 2022-04-13 14:33 ` kernel test robot
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=98d190a3-b3f3-0fa5-be0f-8d602ffe7aea@infradead.org \ --to=rdunlap@infradead.org \ --cc=akpm@linux-foundation.org \ --cc=arnd@arndb.de \ --cc=gregkh@linuxfoundation.org \ --cc=libo.chen@oracle.com \ --cc=linux-arch@vger.kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kbuild@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=masahiroy@kernel.org \ --cc=mingo@kernel.org \ --cc=peterz@infradead.org \ --cc=tglx@linutronix.de \ --cc=vbabka@suse.cz \ /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: linkBe 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.