public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ravikiran G Thirumalai <kiran@scalex86.org>
To: Pekka Enberg <penberg@cs.helsinki.fi>
Cc: Christoph Lameter <clameter@engr.sgi.com>,
	akpm@osdl.org, linux-kernel@vger.kernel.org, clameter@sgi.com,
	manfred@colorfullife.com, mark.fasheh@oracle.com,
	alok.kataria@calsoftinc.com
Subject: Re: [PATCH] slab: Don't scan cache_cache
Date: Sun, 26 Feb 2006 18:25:03 -0800	[thread overview]
Message-ID: <20060227022503.GC3590@localhost.localdomain> (raw)
In-Reply-To: <1140904214.11182.1.camel@localhost>

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 <penberg@cs.helsinki.fi>
> > 
> > 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

      reply	other threads:[~2006-02-27  2:24 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-24  7:52 [PATCH] slab: Don't scan cache_cache Pekka J Enberg
2006-02-24 16:16 ` Christoph Lameter
2006-02-25 21:50   ` Pekka Enberg
2006-02-27  2:25     ` Ravikiran G Thirumalai [this message]

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=20060227022503.GC3590@localhost.localdomain \
    --to=kiran@scalex86.org \
    --cc=akpm@osdl.org \
    --cc=alok.kataria@calsoftinc.com \
    --cc=clameter@engr.sgi.com \
    --cc=clameter@sgi.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=manfred@colorfullife.com \
    --cc=mark.fasheh@oracle.com \
    --cc=penberg@cs.helsinki.fi \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox