Re: [PATCH] slab: Don't scan cache_cache

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, Feb 25, 2006 at 11:50:13PM +0200, Pekka Enberg wrote:
> On Fri, 24 Feb 2006, Pekka J Enberg wrote:
> > > From: Pekka Enberg <[email protected]>
> > 
> > Are you really seeing any measurable regression?
> 
> I haven't measured it but it seems obvious enough that especially for
> low end boxes. I don't think something more general is required because
> other static caches should use kmalloc() instead.
> 

I hope all of us mean "less used and not changing in usage over time"  when we
refer to static caches all throughout our discussion.  That said, for a
given workload,  one set of caches maybe static while the other is not
(networking loads may have networking slab caches grow and shrink, while the
fs driver caches stay static etc).  So I am not sure if static caches can
use kmalloc in general.  If scanning cache_cache is really a regression (it is
probably 1 of 15-20 other static caches on a system), then  IMHO, similar
treatment should be given to other static caches as well.  We could have a
counter on cachep (per-cpu of course) which keeps tracks of cachep usage,
and we could build logic not to scan these caches as frequently.

Now, it is not like cache_cache cannot grow at all or is absolutely static.
So not scanning just cache_cache, when SLAB_NO_REAP flag is taken out
does not make it look very good IMHO.  Sure, it was this way before, but
we had a flag to indicate so.  And if we think this is a regression, we
should generalize this for other less used caches too.

Thanks,
Kiran
-
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]
  Powered by Linux