mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Ravikiran G Thirumalai <kiran@scalex86.org>
To: Christoph Lameter <clameter@engr.sgi.com>
Cc: Andrew Morton <akpm@osdl.org>,
	alokk@calsoftinc.com, manfred@colorfullife.com,
	penberg@gmail.com, linux-kernel@vger.kernel.org
Subject: Re: Slab: Node rotor for freeing alien caches and remote per cpu pages.
Date: Thu, 23 Feb 2006 17:28:15 -0800	[thread overview]
Message-ID: <20060224012815.GB5589@localhost.localdomain> (raw)
In-Reply-To: <Pine.LNX.4.64.0602231140140.13899@schroedinger.engr.sgi.com>

On Thu, Feb 23, 2006 at 11:41:51AM -0800, Christoph Lameter wrote:
> On Thu, 23 Feb 2006, Andrew Morton wrote:
> 
> > Christoph Lameter <clameter@engr.sgi.com> wrote:
> > >
> > > The cache reaper currently tries to free all alien caches and all remote
> > >  per cpu pages in each pass of cache_reap.
> > 
> > umm, why?  We have a reap timer per cpu - why doesn't each CPU drain its
> > own stuff and its own node's stuff and leave the other nodes&cpus alone?
> 
> Each cpu has per cpu pages on remote nodes and also has alien caches 
> on remote nodes. These are only accessible from the processor using them.

Actually, all cpus on the node share the alien_cache, and the alien_cache is
one per remote node (for the cachep).  So currently each cpu on the node 
drains the same alien_cache onto all the remote nodes in the per-cpu eventd.  

What is probably very expensive here at drain_alien_cache is free_block 
getting called from the foreign node, and freeing remote pages.
We have a patch-set here to drop-in the alien objects from the current node to 
the respective alien node's drop box, and that drop box will be cleared
locally (so that freeing happens locally).  This would happen off cache_reap. 
(I was holding from posting it because akpm complained about slab.c 
being full on -mm.  Maybe I should post it now...).   

Round robin might still be useful for drain_alien_cache with that approach, 
but maybe init_reap_node should initialize the per-cpu reap_node with a skew
for cpus on the same node (so all cpus of a node do not drain to the same 
foreign node when the eventd runs?)

Round robin for drain_remote_pages is going to be useful for us too I think.

Thanks,
Kiran

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

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-23 18:43 Christoph Lameter
2006-02-23 19:33 ` Andrew Morton
2006-02-23 19:41   ` Christoph Lameter
2006-02-24  1:28     ` Ravikiran G Thirumalai [this message]
2006-02-24  2:25       ` Christoph Lameter
2006-02-24  8:31         ` Ravikiran G Thirumalai
2006-02-23 21:53 ` Christoph Lameter
2006-02-24  0:59 ` Andrew Morton
2006-02-24  1:17   ` Christoph Lameter

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=20060224012815.GB5589@localhost.localdomain \
    --to=kiran@scalex86.org \
    --cc=akpm@osdl.org \
    --cc=alokk@calsoftinc.com \
    --cc=clameter@engr.sgi.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=manfred@colorfullife.com \
    --cc=penberg@gmail.com \
    /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

Powered by JetHome