The LOCKDEP_*_BITS configs control the size of internal structures used
by lockdep. The size is calculated as a power of two of the configured
value (e.g. 16 => 64KB). Update these descriptions to more accurately
reflect this, as "Bitsize" can be misleading.
Suggested-by: Andrew Morton <akpm@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Boqun Feng <boqun.feng@gmail.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Waiman Long <longman@redhat.com>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: Carlos Llamas <cmllamas@google.com>
---
lib/Kconfig.debug | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index baaaedfde0cb..e0614a415348 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -1505,7 +1505,7 @@ config LOCKDEP_SMALL
bool
config LOCKDEP_BITS
- int "Bitsize for MAX_LOCKDEP_ENTRIES"
+ int "Size for MAX_LOCKDEP_ENTRIES (as Nth power of 2)"
depends on LOCKDEP && !LOCKDEP_SMALL
range 10 24
default 15
@@ -1513,7 +1513,7 @@ config LOCKDEP_BITS
Try increasing this value if you hit "BUG: MAX_LOCKDEP_ENTRIES too low!" message.
config LOCKDEP_CHAINS_BITS
- int "Bitsize for MAX_LOCKDEP_CHAINS"
+ int "Size for MAX_LOCKDEP_CHAINS (as Nth power of 2)"
depends on LOCKDEP && !LOCKDEP_SMALL
range 10 21
default 16
@@ -1521,7 +1521,7 @@ config LOCKDEP_CHAINS_BITS
Try increasing this value if you hit "BUG: MAX_LOCKDEP_CHAINS too low!" message.
config LOCKDEP_STACK_TRACE_BITS
- int "Bitsize for MAX_STACK_TRACE_ENTRIES"
+ int "Size for MAX_STACK_TRACE_ENTRIES (as Nth power of 2)"
depends on LOCKDEP && !LOCKDEP_SMALL
range 10 26
default 19
@@ -1529,7 +1529,7 @@ config LOCKDEP_STACK_TRACE_BITS
Try increasing this value if you hit "BUG: MAX_STACK_TRACE_ENTRIES too low!" message.
config LOCKDEP_STACK_TRACE_HASH_BITS
- int "Bitsize for STACK_TRACE_HASH_SIZE"
+ int "Size for STACK_TRACE_HASH_SIZE (as Nth power of 2)"
depends on LOCKDEP && !LOCKDEP_SMALL
range 10 26
default 14
@@ -1537,7 +1537,7 @@ config LOCKDEP_STACK_TRACE_HASH_BITS
Try increasing this value if you need large STACK_TRACE_HASH_SIZE.
config LOCKDEP_CIRCULAR_QUEUE_BITS
- int "Bitsize for elements in circular_queue struct"
+ int "Size for elements in circular_queue struct (as Nth power of 2)"
depends on LOCKDEP
range 10 26
default 12
--
2.46.0.rc2.264.g509ed76dc8-googOn 8/5/24 21:01, Carlos Llamas wrote: > The LOCKDEP_*_BITS configs control the size of internal structures used > by lockdep. The size is calculated as a power of two of the configured > value (e.g. 16 => 64KB). Update these descriptions to more accurately > reflect this, as "Bitsize" can be misleading. > > Suggested-by: Andrew Morton <akpm@linux-foundation.org> > Cc: Peter Zijlstra <peterz@infradead.org> > Cc: Boqun Feng <boqun.feng@gmail.com> > Cc: Ingo Molnar <mingo@redhat.com> > Cc: Waiman Long <longman@redhat.com> > Cc: Will Deacon <will@kernel.org> > Signed-off-by: Carlos Llamas <cmllamas@google.com> > --- > lib/Kconfig.debug | 10 +++++----- > 1 file changed, 5 insertions(+), 5 deletions(-) > > diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug > index baaaedfde0cb..e0614a415348 100644 > --- a/lib/Kconfig.debug > +++ b/lib/Kconfig.debug > @@ -1505,7 +1505,7 @@ config LOCKDEP_SMALL > bool > > config LOCKDEP_BITS > - int "Bitsize for MAX_LOCKDEP_ENTRIES" > + int "Size for MAX_LOCKDEP_ENTRIES (as Nth power of 2)" > depends on LOCKDEP && !LOCKDEP_SMALL > range 10 24 > default 15 > @@ -1513,7 +1513,7 @@ config LOCKDEP_BITS > Try increasing this value if you hit "BUG: MAX_LOCKDEP_ENTRIES too low!" message. > > config LOCKDEP_CHAINS_BITS > - int "Bitsize for MAX_LOCKDEP_CHAINS" > + int "Size for MAX_LOCKDEP_CHAINS (as Nth power of 2)" > depends on LOCKDEP && !LOCKDEP_SMALL > range 10 21 > default 16 > @@ -1521,7 +1521,7 @@ config LOCKDEP_CHAINS_BITS > Try increasing this value if you hit "BUG: MAX_LOCKDEP_CHAINS too low!" message. > > config LOCKDEP_STACK_TRACE_BITS > - int "Bitsize for MAX_STACK_TRACE_ENTRIES" > + int "Size for MAX_STACK_TRACE_ENTRIES (as Nth power of 2)" > depends on LOCKDEP && !LOCKDEP_SMALL > range 10 26 > default 19 > @@ -1529,7 +1529,7 @@ config LOCKDEP_STACK_TRACE_BITS > Try increasing this value if you hit "BUG: MAX_STACK_TRACE_ENTRIES too low!" message. > > config LOCKDEP_STACK_TRACE_HASH_BITS > - int "Bitsize for STACK_TRACE_HASH_SIZE" > + int "Size for STACK_TRACE_HASH_SIZE (as Nth power of 2)" > depends on LOCKDEP && !LOCKDEP_SMALL > range 10 26 > default 14 > @@ -1537,7 +1537,7 @@ config LOCKDEP_STACK_TRACE_HASH_BITS > Try increasing this value if you need large STACK_TRACE_HASH_SIZE. > > config LOCKDEP_CIRCULAR_QUEUE_BITS > - int "Bitsize for elements in circular_queue struct" > + int "Size for elements in circular_queue struct (as Nth power of 2)" > depends on LOCKDEP > range 10 26 > default 12 Many kernel developers understand that BITS refers to a size of 2^n. Besides LOCKDEP, there are also many instances of such use in other kconfig entries. It can be a bit odd to explicitly state that just for LOCKDEP. Cheers, Longman
On Mon, Aug 05, 2024 at 09:36:43PM -0400, Waiman Long wrote: > > Many kernel developers understand that BITS refers to a size of 2^n. Besides > LOCKDEP, there are also many instances of such use in other kconfig entries. > It can be a bit odd to explicitly state that just for LOCKDEP. > > Cheers, > Longman Right, and similar to BITS there is SHIFT, which is also a common way to specify the 2^n values. I'd point out though, that it is also common to clarify the "power of two" explicitly. To name a few examples that are doing so: SECURITY_SELINUX_SIDTAB_HASH_BITS, NODES_SHIFT, CMA_ALIGNMENT, IP_VS_SH_TAB_BITS, LOG_BUF_SHIFT but there is more. Perhaps this is because the audience for these configs is not always a kernel developer? Anyway, this is pretty much a trivial patch to address Andrew's comment below. But let me know if you think I should drop it, it seems to me it can be helpful. [...] btw, the help text "Bitsize for MAX_LOCKDEP_CHAINS" is odd. What's a bitsize? Maybe "bit shift count for..." or such. Thanks, -- Carlos Llamas
On 8/6/24 10:47, Carlos Llamas wrote: > On Mon, Aug 05, 2024 at 09:36:43PM -0400, Waiman Long wrote: >> Many kernel developers understand that BITS refers to a size of 2^n. Besides >> LOCKDEP, there are also many instances of such use in other kconfig entries. >> It can be a bit odd to explicitly state that just for LOCKDEP. >> >> Cheers, >> Longman > Right, and similar to BITS there is SHIFT, which is also a common way to > specify the 2^n values. I'd point out though, that it is also common to > clarify the "power of two" explicitly. To name a few examples that are > doing so: SECURITY_SELINUX_SIDTAB_HASH_BITS, NODES_SHIFT, CMA_ALIGNMENT, > IP_VS_SH_TAB_BITS, LOG_BUF_SHIFT but there is more. > > Perhaps this is because the audience for these configs is not always a > kernel developer? > > Anyway, this is pretty much a trivial patch to address Andrew's comment > below. But let me know if you think I should drop it, it seems to me it > can be helpful. > > [...] > btw, the help text "Bitsize for MAX_LOCKDEP_CHAINS" is odd. What's a > bitsize? Maybe "bit shift count for..." or such. I am not against this patch. Currently I am neutral. Let's see what Boqun think about it. Cheers, Longman
On Tue, Aug 06, 2024 at 10:52:52AM -0400, Waiman Long wrote: > > On 8/6/24 10:47, Carlos Llamas wrote: > > On Mon, Aug 05, 2024 at 09:36:43PM -0400, Waiman Long wrote: > > > Many kernel developers understand that BITS refers to a size of 2^n. Besides > > > LOCKDEP, there are also many instances of such use in other kconfig entries. > > > It can be a bit odd to explicitly state that just for LOCKDEP. > > > > > > Cheers, > > > Longman > > Right, and similar to BITS there is SHIFT, which is also a common way to > > specify the 2^n values. I'd point out though, that it is also common to > > clarify the "power of two" explicitly. To name a few examples that are > > doing so: SECURITY_SELINUX_SIDTAB_HASH_BITS, NODES_SHIFT, CMA_ALIGNMENT, > > IP_VS_SH_TAB_BITS, LOG_BUF_SHIFT but there is more. > > > > Perhaps this is because the audience for these configs is not always a > > kernel developer? > > > > Anyway, this is pretty much a trivial patch to address Andrew's comment > > below. But let me know if you think I should drop it, it seems to me it > > can be helpful. > > > > [...] > > btw, the help text "Bitsize for MAX_LOCKDEP_CHAINS" is odd. What's a > > bitsize? Maybe "bit shift count for..." or such. > > I am not against this patch. Currently I am neutral. Let's see what Boqun > think about it. > This looks good to me. Maybe it's a bit verbose but that's what the doc part should be: providing enough information so more people can be on the same page. Please keep this one, thanks! Regards, Boqun > Cheers, > Longman >
On Tue, Aug 06, 2024 at 10:42:52AM -0700, Boqun Feng wrote: > On Tue, Aug 06, 2024 at 10:52:52AM -0400, Waiman Long wrote: > > > > On 8/6/24 10:47, Carlos Llamas wrote: > > > On Mon, Aug 05, 2024 at 09:36:43PM -0400, Waiman Long wrote: > > > > Many kernel developers understand that BITS refers to a size of 2^n. Besides > > > > LOCKDEP, there are also many instances of such use in other kconfig entries. > > > > It can be a bit odd to explicitly state that just for LOCKDEP. > > > > > > > > Cheers, > > > > Longman > > > Right, and similar to BITS there is SHIFT, which is also a common way to > > > specify the 2^n values. I'd point out though, that it is also common to > > > clarify the "power of two" explicitly. To name a few examples that are > > > doing so: SECURITY_SELINUX_SIDTAB_HASH_BITS, NODES_SHIFT, CMA_ALIGNMENT, > > > IP_VS_SH_TAB_BITS, LOG_BUF_SHIFT but there is more. > > > > > > Perhaps this is because the audience for these configs is not always a > > > kernel developer? > > > > > > Anyway, this is pretty much a trivial patch to address Andrew's comment > > > below. But let me know if you think I should drop it, it seems to me it > > > can be helpful. > > > > > > [...] > > > btw, the help text "Bitsize for MAX_LOCKDEP_CHAINS" is odd. What's a > > > bitsize? Maybe "bit shift count for..." or such. > > > > I am not against this patch. Currently I am neutral. Let's see what Boqun > > think about it. > > > > This looks good to me. Maybe it's a bit verbose but that's what the doc > part should be: providing enough information so more people can be on > the same page. Please keep this one, thanks! Sounds good. I'll send out the v2 and keep this patch then. Thanks, Carlos Llamas
© 2016 - 2025 Red Hat, Inc.