[PATCH] debugobjects: Allow to configure the amount of pre-allocated objects

[PATCH] debugobjects: Allow to configure the amount of pre-allocated objects

[Benjamin Block]

To debug object operations a certain amount of metadata has to be kept
per object that is tracked. During boot a static amount of pre-
allocated objects is set aside to be used for this task until such a
time a dynamic allocator can be used. Once a dynamic allocator can be
used an initial amount of objects is pre-allocated to be used when
needed.

So far the amount of such initially statically, and later dynamically
pre-allocated objects is set fixed at `64 * 16 = 1024`. But depending on
the system this might not be enough during boot, when only the static
amount of pre-allocated objects is used; and once this happens ODEBUG
disables itself permanently.

On s390 it has been observed, that even with 16384 such pre-allocated
objects ODEBUG would still be disabled during boot.

Similarly to other debug features like KMEMLEAK add a Kconfig option
CONFIG_DEBUG_OBJECTS_POOL_SIZE_SHIFT that allows to increase the amount
of pre-allocated objects (in both the static and later dynamic cases).
Use it as exponential, rather than linear value to allow for head-room
to grow into once set in a configuration.

The calculation is done as such:
    N_OBJECTS = 2^DEBUG_OBJECTS_POOL_SIZE_SHIFT * N_BATCH

By default it is set to 6, so the actual amount is unchanged, unless
the new options is changed:
    N_OBJECTS = 2^6 * 16
    N_OBJECTS = 1024

For the previously mentioned observations on s390 it was necessary to
increase the option to 11 in order to have enough space during boot.

Signed-off-by: Benjamin Block <bblock@linux.ibm.com>
---
 lib/Kconfig.debug  | 32 ++++++++++++++++++++++++++++++++
 lib/debugobjects.c | 15 +++++++++++++--
 2 files changed, 45 insertions(+), 2 deletions(-)

diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 318df4c75454..c6afc5b03572 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -811,6 +811,38 @@ config DEBUG_OBJECTS_PERCPU_COUNTER
 	  percpu counter routines to track the life time of percpu counter
 	  objects and validate the percpu counter operations.
 
+config DEBUG_OBJECTS_POOL_SIZE_SHIFT
+	int "Metadata objects pool size"
+	depends on DEBUG_OBJECTS
+	range 0 21
+	default 6
+	help
+	  To debug object operations a certain amount of metadata has to be
+	  kept per object that is tracked. During boot a static amount of pre-
+	  allocated objects is set aside to be used for this task until such a
+	  time a dynamic allocator can be used. Once a dynamic allocator can be
+	  used an initial amount of objects is pre-allocated to be used when
+	  needed.
+
+	  This option sets the amount of both: the amount of initially
+	  statically allocated objects; and later the amount of dynamically
+	  pre-allocated objects. It is used as exponent to the power of 2,
+	  multiplied by the batch size used to set how many objects are move
+	  between pools at once.
+
+	  For example, when left at the default of 6:
+	      N_OBJECTS = 2^DEBUG_OBJECTS_POOL_SIZE_SHIFT * N_BATCH
+	      N_OBJECTS = 2^6 * 16
+	      N_OBJECTS = 1024
+	  By increasing the option by 1, you double the amount of objects.
+
+	  An indication that you need to increase this option is that during
+	  boot you see messages like this:
+	      ODEBUG: Out of memory. ODEBUG disabled
+
+	  If in doubt, leave the default.
+
+
 config DEBUG_OBJECTS_ENABLE_DEFAULT
 	int "debug_objects bootup default value (0-1)"
 	range 0 1
diff --git a/lib/debugobjects.c b/lib/debugobjects.c
index 89a1d6745dc2..20e93d0074fa 100644
--- a/lib/debugobjects.c
+++ b/lib/debugobjects.c
@@ -22,11 +22,18 @@
 #define ODEBUG_HASH_BITS	14
 #define ODEBUG_HASH_SIZE	(1 << ODEBUG_HASH_BITS)
 
-/* Must be power of two */
+/*
+ * Must be power of two.
+ * Please change Kconfig help text of DEBUG_OBJECTS_POOL_SIZE_SHIFT when
+ * changed.
+ */
 #define ODEBUG_BATCH_SIZE	16
 
+#define ODEBUG_POOL_SHIFT	CONFIG_DEBUG_OBJECTS_POOL_SIZE_SHIFT
+static_assert(ODEBUG_POOL_SHIFT >= 0);
+
 /* Initial values. Must all be a multiple of batch size */
-#define ODEBUG_POOL_SIZE	(64 * ODEBUG_BATCH_SIZE)
+#define ODEBUG_POOL_SIZE	((1 << ODEBUG_POOL_SHIFT) * ODEBUG_BATCH_SIZE)
 #define ODEBUG_POOL_MIN_LEVEL	(ODEBUG_POOL_SIZE / 4)
 
 #define ODEBUG_POOL_PERCPU_SIZE	(8 * ODEBUG_BATCH_SIZE)
@@ -569,6 +576,10 @@ static void debug_objects_oom(void)
 	struct debug_bucket *db = obj_hash;
 	HLIST_HEAD(freelist);
 
+	/*
+	 * Please change Kconfig help text of DEBUG_OBJECTS_POOL_SIZE_SHIFT
+	 * when changed.
+	 */
 	pr_warn("Out of memory. ODEBUG disabled\n");
 
 	for (int i = 0; i < ODEBUG_HASH_SIZE; i++, db++) {
-- 
2.53.0

Re: [PATCH] debugobjects: Allow to configure the amount of pre-allocated objects

[Benjamin Block]

On Wed, Feb 25, 2026 at 05:05:08PM +0100, Benjamin Block wrote:
> To debug object operations a certain amount of metadata has to be kept
> per object that is tracked. During boot a static amount of pre-
> allocated objects is set aside to be used for this task until such a
> time a dynamic allocator can be used. Once a dynamic allocator can be
> used an initial amount of objects is pre-allocated to be used when
> needed.
> 
> So far the amount of such initially statically, and later dynamically
> pre-allocated objects is set fixed at `64 * 16 = 1024`. But depending on
> the system this might not be enough during boot, when only the static
> amount of pre-allocated objects is used; and once this happens ODEBUG
> disables itself permanently.
> 
> On s390 it has been observed, that even with 16384 such pre-allocated
> objects ODEBUG would still be disabled during boot.
> 
> Similarly to other debug features like KMEMLEAK add a Kconfig option
> CONFIG_DEBUG_OBJECTS_POOL_SIZE_SHIFT that allows to increase the amount
> of pre-allocated objects (in both the static and later dynamic cases).
> Use it as exponential, rather than linear value to allow for head-room
> to grow into once set in a configuration.
> 
> The calculation is done as such:
>     N_OBJECTS = 2^DEBUG_OBJECTS_POOL_SIZE_SHIFT * N_BATCH
> 
> By default it is set to 6, so the actual amount is unchanged, unless
> the new options is changed:
>     N_OBJECTS = 2^6 * 16
>     N_OBJECTS = 1024
> 
> For the previously mentioned observations on s390 it was necessary to
> increase the option to 11 in order to have enough space during boot.
> 
> Signed-off-by: Benjamin Block <bblock@linux.ibm.com>
> ---
>  lib/Kconfig.debug  | 32 ++++++++++++++++++++++++++++++++
>  lib/debugobjects.c | 15 +++++++++++++--
>  2 files changed, 45 insertions(+), 2 deletions(-)

Gentle ping, any comments at all for tis?

-- 
Best Regards, Benjamin Block        /        Linux on IBM Z Kernel Development
IBM Deutschland Research & Development GmbH    /   https://www.ibm.com/privacy
Vors. Aufs.-R.: Wolfgang Wendt         /        Geschäftsführung: David Faller
Sitz der Ges.: Ehningen     /     Registergericht: AmtsG Stuttgart, HRB 243294

Re: [PATCH] debugobjects: Allow to configure the amount of pre-allocated objects

[Andrew Morton]

On Wed, 11 Mar 2026 11:04:31 +0100 Benjamin Block <bblock@linux.ibm.com> wrote:

> > ---
> >  lib/Kconfig.debug  | 32 ++++++++++++++++++++++++++++++++
> >  lib/debugobjects.c | 15 +++++++++++++--
> >  2 files changed, 45 insertions(+), 2 deletions(-)
> 
> Gentle ping, any comments at all for tis?

Normally tglx stuff, but lgtm so I'll add it to mm.git and linux-next
for some test.

obj_static_pool[] is __initdata, so the consequences of making it large
are very slight.  So do we really need
CONFIG_DEBUG_OBJECTS_POOL_SIZE_SHIFT?  Requiring a rebuild is a huge
hassle.  How about simply making the static pool much larger and leave
it at that?  Some statement (or, better, comment) which reveals the
number of bytes which are (temporarily) consumed would be useful.

Re: [PATCH] debugobjects: Allow to configure the amount of pre-allocated objects

[Benjamin Block]

On Wed, Mar 11, 2026 at 10:47:27AM -0700, Andrew Morton wrote:
> On Wed, 11 Mar 2026 11:04:31 +0100 Benjamin Block <bblock@linux.ibm.com> wrote:
> 
> > > ---
> > >  lib/Kconfig.debug  | 32 ++++++++++++++++++++++++++++++++
> > >  lib/debugobjects.c | 15 +++++++++++++--
> > >  2 files changed, 45 insertions(+), 2 deletions(-)
> > 
> > Gentle ping, any comments at all for tis?
> 
> Normally tglx stuff, but lgtm so I'll add it to mm.git and linux-next
> for some test.

Thanks.

> obj_static_pool[] is __initdata, so the consequences of making it large
> are very slight.  So do we really need
> CONFIG_DEBUG_OBJECTS_POOL_SIZE_SHIFT?  Requiring a rebuild is a huge
> hassle.  How about simply making the static pool much larger and leave
> it at that?

I was thinking about that but then couldn't decide what would be "big enough"
as constant value for "everyone". My test systems wasn't even that "big", and
I'm already at 1280 KiB reservation to make ODEBUG "survive" the boot. Not
sure I want to make this say 2 MiB without config option for everyone.

> Some statement (or, better, comment) which reveals the number of bytes which
> are (temporarily) consumed would be useful.

-- 
Best Regards, Benjamin Block        /        Linux on IBM Z Kernel Development
IBM Deutschland Research & Development GmbH    /   https://www.ibm.com/privacy
Vors. Aufs.-R.: Wolfgang Wendt         /        Geschäftsführung: David Faller
Sitz der Ges.: Ehningen     /     Registergericht: AmtsG Stuttgart, HRB 243294

Re: [PATCH] debugobjects: Allow to configure the amount of pre-allocated objects

[Andrew Morton]

On Fri, 13 Mar 2026 15:26:20 +0100 Benjamin Block <bblock@linux.ibm.com> wrote:

> > obj_static_pool[] is __initdata, so the consequences of making it large
> > are very slight.  So do we really need
> > CONFIG_DEBUG_OBJECTS_POOL_SIZE_SHIFT?  Requiring a rebuild is a huge
> > hassle.  How about simply making the static pool much larger and leave
> > it at that?
> 
> I was thinking about that but then couldn't decide what would be "big enough"
> as constant value for "everyone". My test systems wasn't even that "big", and
> I'm already at 1280 KiB reservation to make ODEBUG "survive" the boot. Not
> sure I want to make this say 2 MiB without config option for everyone.

2MB of initmem probably just doesn't matter.  Annoying.

Do you understand *why* s390 is using so many objects?  Presumably the
current much smaller default is OK for most systems - my googling for
"Out of memory.  ODEBUG disabled" turned up very little.

Oh, look what I found. 
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1807440.html
What happened to that?

Re: [PATCH] debugobjects: Allow to configure the amount of pre-allocated objects

[Benjamin Block]

On Sat, Mar 14, 2026 at 03:06:49PM -0700, Andrew Morton wrote:
> On Fri, 13 Mar 2026 15:26:20 +0100 Benjamin Block <bblock@linux.ibm.com> wrote:
> 
> > > obj_static_pool[] is __initdata, so the consequences of making it large
> > > are very slight.  So do we really need
> > > CONFIG_DEBUG_OBJECTS_POOL_SIZE_SHIFT?  Requiring a rebuild is a huge
> > > hassle.  How about simply making the static pool much larger and leave
> > > it at that?
> > 
> > I was thinking about that but then couldn't decide what would be "big enough"
> > as constant value for "everyone". My test systems wasn't even that "big", and
> > I'm already at 1280 KiB reservation to make ODEBUG "survive" the boot. Not
> > sure I want to make this say 2 MiB without config option for everyone.
> 
> 2MB of initmem probably just doesn't matter.  Annoying.
> 
> Do you understand *why* s390 is using so many objects?  Presumably the
> current much smaller default is OK for most systems - my googling for
> "Out of memory.  ODEBUG disabled" turned up very little.

Frankly, I don't know where all the objects come from on s390. I'll do some
digging, and try to trace the sources.. let's see what I can manage; but I'll
be on a trip for a couple of days.

> Oh, look what I found. 
> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1807440.html
> What happened to that?

Interesting, indeed. Nr. of CPUs and Memory. Well, I had 32 processors and 64
GiB memory, which all things considered isn't particularly huge these days.

-- 
Best Regards, Benjamin Block        /        Linux on IBM Z Kernel Development
IBM Deutschland Research & Development GmbH    /   https://www.ibm.com/privacy
Vors. Aufs.-R.: Wolfgang Wendt         /        Geschäftsführung: David Faller
Sitz der Ges.: Ehningen     /     Registergericht: AmtsG Stuttgart, HRB 243294

Re: [PATCH] debugobjects: Allow to configure the amount of pre-allocated objects

[Thomas Gleixner]

On Wed, Feb 25 2026 at 17:05, Benjamin Block wrote:
> On s390 it has been observed, that even with 16384 such pre-allocated
> objects ODEBUG would still be disabled during boot.
>
> Similarly to other debug features like KMEMLEAK add a Kconfig option
> CONFIG_DEBUG_OBJECTS_POOL_SIZE_SHIFT that allows to increase the amount
> of pre-allocated objects (in both the static and later dynamic cases).
> Use it as exponential, rather than linear value to allow for head-room
> to grow into once set in a configuration.
>
> The calculation is done as such:
>     N_OBJECTS = 2^DEBUG_OBJECTS_POOL_SIZE_SHIFT * N_BATCH
>
> By default it is set to 6, so the actual amount is unchanged, unless
> the new options is changed:
>     N_OBJECTS = 2^6 * 16
>     N_OBJECTS = 1024
>
> For the previously mentioned observations on s390 it was necessary to
> increase the option to 11 in order to have enough space during boot.

That doesn't make sense. The only phase where debug objects needs to
allocate from the preallocated static pool is the time before the memory
allocator becomes available. I doubt that this early boot phase eats 16k
or more objects.

This smells like the problem I fixed recently:

  fd3634312a04 ("debugobject: Make it work with deferred page initialization - again")

Looks that I missed to add a cc:stable for it.

Thanks,

        tglx