On Fri, 29 Sep 2006 23:58:42 -0000
Thomas Gleixner <[email protected]> wrote:
> From: Ingo Molnar <[email protected]>
>
> decrease the rate of SLAB timers going off. Reduces the amount
> of timers going off in an idle system.
>
> Signed-off-by: Ingo Molnar <[email protected]>
> Signed-off-by: Thomas Gleixner <[email protected]>
> --
> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
