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

From: Andrew Morton
Date: Sat Sep 30 2006 - 04:49:53 EST


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

> From: Ingo Molnar <mingo@xxxxxxx>
>
> 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@xxxxxxx>
> Signed-off-by: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
> --
> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/