All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Qian Cai" <cai@gmx.us>
To: "Waiman Long" <longman@redhat.com>
Cc: tglx@linutronix.de, akpm@linux-foundation.org,
	linux-kernel@vger.kernel.org, yang.shi@linux.alibaba.com,
	arnd@arndb.de
Subject: Re: [PATCH v3] debugobjects: scale the static pool size
Date: Wed, 21 Nov 2018 00:54:21 +0100	[thread overview]
Message-ID: <trinity-ce6c61be-cc03-4a9d-8f26-562694d048da-1542758061535@msvc-mesg-gmx023> (raw)
In-Reply-To: <e286be8a-7f0a-65ab-0275-15abcd33eb07@redhat.com>

On 11/20/18 at 6:38 PM, Waiman Long wrote:

> On 11/20/2018 06:28 PM, Qian Cai wrote:
> > The current value of the early boot static pool size is not big enough
> > for systems with large number of CPUs with timer or/and workqueue
> > objects selected. As the results, systems have 60+ CPUs with both timer
> > and workqueue objects enabled could trigger "ODEBUG: Out of memory.
> > ODEBUG disabled". Hence, fixed it by computing it according to
> > CONFIG_NR_CPUS and CONFIG_DEBUG_OBJECTS_* options.
> >
> > Signed-off-by: Qian Cai <cai@gmx.us>
> > ---
> > Changes since v2:
> > * Made the calculation easier to read suggested by longman@redhat.com.
> >
> > Changes since v1:
> > * Removed the CONFIG_NR_CPUS check since it is always defined.
> > * Introduced a minimal default pool size to start with. Otherwise, the pool
> >   size would be too low for systems only with a small number of CPUs.
> > * Adjusted the scale factors according to data.
> >
> >  lib/debugobjects.c | 82 ++++++++++++++++++++++++++++++++++++++++++++--
> >  1 file changed, 80 insertions(+), 2 deletions(-)
> >
> > diff --git a/lib/debugobjects.c b/lib/debugobjects.c
> > index 70935ed91125..02456a1e57cb 100644
> > --- a/lib/debugobjects.c
> > +++ b/lib/debugobjects.c
> > @@ -23,9 +23,82 @@
> >  #define ODEBUG_HASH_BITS	14
> >  #define ODEBUG_HASH_SIZE	(1 << ODEBUG_HASH_BITS)
> >  
> > -#define ODEBUG_POOL_SIZE	1024
> > +#define ODEBUG_DEFAULT_POOL	512
> >  #define ODEBUG_POOL_MIN_LEVEL	256
> >  
> > +/*
> > + * Some debug objects are allocated during the early boot. Enabling some
> > + * options like timers or workqueue objects may increase the size required
> > + * significantly with large number of CPUs. For example (as today, 20 Nov.
> > + * 2018),
> > + *
> > + * No. CPUs x 2 (worker pool) objects:
> > + *
> > + * start_kernel
> > + *   workqueue_init_early
> > + *     init_worker_pool
> > + *       init_timer_key
> > + *         debug_object_init
> > + *
> > + * No. CPUs objects (CONFIG_HIGH_RES_TIMERS):
> > + *
> > + * sched_init
> > + *   hrtick_rq_init
> > + *     hrtimer_init
> > + *
> > + * CONFIG_DEBUG_OBJECTS_WORK:
> > + * No. CPUs x 6 (workqueue) objects:
> > + *
> > + * workqueue_init_early
> > + *   alloc_workqueue
> > + *     __alloc_workqueue_key
> > + *       alloc_and_link_pwqs
> > + *         init_pwq
> > + *
> > + * Also, plus No. CPUs objects:
> > + *
> > + * perf_event_init
> > + *    __init_srcu_struct
> > + *      init_srcu_struct_fields
> > + *        init_srcu_struct_nodes
> > + *          __init_work
> > + *
> > + * Increase the number a bit more in case the implmentatins are changed in
> > + * the future, as it is better to avoid OOM than spending a bit more kernel
> > + * memory that will/can be freed.
> > + *
> > + * With all debug objects config options selected except the workqueue and
> > + * the timers, kernel reports,
> > + * 64-CPU:  ODEBUG: 4 of 4 active objects replaced
> > + * 256-CPU: ODEBUG: 4 of 4 active objects replaced
> > + *
> > + * all the options except the workqueue:
> > + * 64-CPU:  ODEBUG: 466 of 466 active objects replaced
> > + * 256-CPU: ODEBUG: 1810 of 1810 active objects replaced
> > + *
> > + * all the options except the timers:
> > + * 64-CPU:  ODEBUG: 652 of 652 active objects replaced
> > + * 256-CPU: ODEBUG: 2572 of 2572 active objects replaced
> > + *
> > + * all the options:
> > + * 64-CPU:  ODEBUG: 1114 of 1114 active objects replaced
> > + * 256-CPU: ODEBUG: 4378 of 4378 active objects replaced
> > + */
> > +#ifdef CONFIG_DEBUG_OBJECTS_WORK
> > +#define ODEBUG_WORK_PCPU_CNT	10
> > +#else
> > +#define ODEBUG_WORK_PCPU_CNT	0
> > +#endif /* CONFIG_DEBUG_OBJECTS_WORK */
> > +
> > +#ifdef CONFIG_DEBUG_OBJECTS_TIMERS
> > +#define ODEBUG_TIMERS_PCPU_CNT	10
> > +#else
> > +#define ODEBUG_TIMERS_PCPU_CNT	0
> > +#endif /* CONFIG_DEBUG_OBJECTS_TIMERS */
> > +
> > +#define ODEBUG_POOL_SIZE	(ODEBUG_DEFAULT_POOL + CONFIG_NR_CPUS * \
> > +(ODEBUG_TIMERS_PCPU_CNT + ODEBUG_WORK_PCPU_CNT))
> 
> Just a nit about indentation. There should be some indentation in the
> continued line.

I am fine to add that, but checkpatch.pl complained
that there should no spaces at the beginning of a
newline. Guess we just ignore the warning?

“please, no spaces at the start of a line”

  reply	other threads:[~2018-11-20 23:54 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-20 20:14 [PATCH v2] debugobjects: scale the static pool size Qian Cai
2018-11-20 20:54 ` Waiman Long
2018-11-20 20:56   ` Thomas Gleixner
2018-11-20 23:28 ` [PATCH v3] " Qian Cai
2018-11-20 23:38   ` Waiman Long
2018-11-20 23:54     ` Qian Cai [this message]
2018-11-20 23:58       ` Joe Perches
2018-11-21  2:11   ` [PATCH v4] " Qian Cai
2018-11-21 14:45     ` Waiman Long
2018-11-22 21:56     ` Thomas Gleixner
2018-11-23  4:31       ` [PATCH] debugobjects: call debug_objects_mem_init eariler Qian Cai
2018-11-23  4:59         ` Waiman Long
2018-11-23 21:46           ` Thomas Gleixner
2018-11-24  2:54             ` Qian Cai
2018-11-24  3:01       ` [PATCH v4] debugobjects: scale the static pool size Qian Cai
2018-11-25 20:42         ` Qian Cai
2018-11-26  1:31           ` Waiman Long
2018-11-26  4:52             ` Qian Cai
2018-11-26  9:45               ` Qian Cai
2018-11-26 10:50                 ` Catalin Marinas
2018-11-25 20:48       ` Qian Cai

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=trinity-ce6c61be-cc03-4a9d-8f26-562694d048da-1542758061535@msvc-mesg-gmx023 \
    --to=cai@gmx.us \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=longman@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=yang.shi@linux.alibaba.com \
    /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 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.