Re: [patch 22/23] dynticks: increase SLAB timeouts

[Andrew Morton <akpm@osdl.org>]

On Fri, 29 Sep 2006 23:58:42 -0000
Thomas Gleixner <tglx@linutronix.de> wrote:

> From: Ingo Molnar <mingo@elte.hu>
> 
> decrease the rate of SLAB timers going off. Reduces the amount
> of timers going off in an idle system.
> 
> Signed-off-by: Ingo Molnar <mingo@elte.hu>
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> --
>  mm/slab.c |    9 +++++++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> Index: linux-2.6.18-mm2/mm/slab.c
> ===================================================================
> --- linux-2.6.18-mm2.orig/mm/slab.c	2006-09-30 01:41:09.000000000 +0200
> +++ linux-2.6.18-mm2/mm/slab.c	2006-09-30 01:41:20.000000000 +0200
> @@ -457,8 +457,13 @@ struct kmem_cache {
>   * OTOH the cpuarrays can contain lots of objects,
>   * which could lock up otherwise freeable slabs.
>   */
> -#define REAPTIMEOUT_CPUC	(2*HZ)
> -#define REAPTIMEOUT_LIST3	(4*HZ)
> +#ifdef CONFIG_NO_HZ
> +# define REAPTIMEOUT_CPUC	(4*HZ)
> +# define REAPTIMEOUT_LIST3	(8*HZ)
> +#else
> +# define REAPTIMEOUT_CPUC	(2*HZ)
> +# define REAPTIMEOUT_LIST3	(4*HZ)
> +#endif
>  
>  #if STATS
>  #define	STATS_INC_ACTIVE(x)	((x)->num_active++)
> 

err, no.

a) We shouldn't go and assume that "No Hz" implies "I want the CPU to
   remain idle for long periods".

   It's a good assumption, but that is an *application* of NO_HZ and the
   above should be a separate configuration option.  Or, better, runtime
   configurable.

b) This reap timeout is there for a reason.  We shouldn't just go and
   modify memory management behaviour because someone selected NO_HZ.

   Again, a runtime tunable is preferable.

Then again, two seconds is quite a long time, surely?  And increasing it to
just four seconds hardly seems worth the effort.


Still, the code you're patching is pretty lame anyway.  It shouldn't be
using time.  Time is meaningless in the mm context.  I'm not sure what it
_should_ be using though.  Perhaps every-Nth-kmem_cache_alloc or something.

It's trying to measure "is this memory I'm holding likely to be in the
CPU's cache any more".  So perhaps time is a close-enough basis.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/