All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mel Gorman <mel@csn.ul.ie>
To: Pekka Enberg <penberg@cs.helsinki.fi>
Cc: Christoph Lameter <cl@linux-foundation.org>,
	Nick Piggin <npiggin@suse.de>,
	heiko.carstens@de.ibm.com, sachinp@in.ibm.com,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	Tejun Heo <tj@kernel.org>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>
Subject: Re: [PATCH 2/4] slqb: Record what node is local to a kmem_cache_cpu
Date: Mon, 5 Oct 2009 10:49:04 +0100	[thread overview]
Message-ID: <20091005094904.GC12681@csn.ul.ie> (raw)
In-Reply-To: <84144f020910040506l24a74660s508c828123c554cc@mail.gmail.com>

On Sun, Oct 04, 2009 at 03:06:45PM +0300, Pekka Enberg wrote:
> On Thu, Oct 1, 2009 at 2:45 AM, Christoph Lameter
> <cl@linux-foundation.org> wrote:
> >> This is essentially the "unqueued" nature of SLUB. It's objective "I have this
> >> page here which I'm going to use until I can't use it no more and will depend
> >> on the page allocator to sort my stuff out". I have to read up on SLUB up
> >> more to see if it's compatible with SLQB or not though. In particular, how
> >> does SLUB deal with frees from pages that are not the "current" page? SLQB
> >> does not care what page the object belongs to as long as it's node-local
> >> as the object is just shoved onto a LIFO for maximum hotness.
> >
> > Frees are done directly to the target slab page if they are not to the
> > current active slab page. No centralized locks. Concurrent frees from
> > processors on the same node to multiple other nodes (or different pages
> > on the same node) can occur.
> >
> >> > SLAB deals with it in fallback_alloc(). It scans the nodes in zonelist
> >> > order for free objects of the kmem_cache and then picks up from the
> >> > nearest node. Ugly but it works. SLQB would have to do something similar
> >> > since it also has the per node object bins that SLAB has.
> >> >
> >>
> >> In a real sense, this is what the patch ends up doing. When it fails to
> >> get something locally but sees that the local node is memoryless, it
> >> will check the remote node lists in zonelist order. I think that's
> >> reasonable behaviour but I'm biased because I just want the damn machine
> >> to boot again. What do you think? Pekka, Nick?
> >
> > Look at fallback_alloc() in slab. You can likely copy much of it. It
> > considers memory policies and cpuset constraints.
> 
> Sorry for the delay. I went ahead and merged Mel's patch to make
> things boot on PPC. Fallback policy needs a bit more work as Christoph
> says but I'd really love to have Nick's input on this.
> 
> Mel, do you have a Kconfig patch laying around somewhere to enable
> SLQB on PPC and S390?
> 

It's patch 4 of this series.

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

WARNING: multiple messages have this Message-ID (diff)
From: Mel Gorman <mel@csn.ul.ie>
To: Pekka Enberg <penberg@cs.helsinki.fi>
Cc: Christoph Lameter <cl@linux-foundation.org>,
	Nick Piggin <npiggin@suse.de>,
	heiko.carstens@de.ibm.com, sachinp@in.ibm.com,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	Tejun Heo <tj@kernel.org>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>
Subject: Re: [PATCH 2/4] slqb: Record what node is local to a kmem_cache_cpu
Date: Mon, 5 Oct 2009 10:49:04 +0100	[thread overview]
Message-ID: <20091005094904.GC12681@csn.ul.ie> (raw)
In-Reply-To: <84144f020910040506l24a74660s508c828123c554cc@mail.gmail.com>

On Sun, Oct 04, 2009 at 03:06:45PM +0300, Pekka Enberg wrote:
> On Thu, Oct 1, 2009 at 2:45 AM, Christoph Lameter
> <cl@linux-foundation.org> wrote:
> >> This is essentially the "unqueued" nature of SLUB. It's objective "I have this
> >> page here which I'm going to use until I can't use it no more and will depend
> >> on the page allocator to sort my stuff out". I have to read up on SLUB up
> >> more to see if it's compatible with SLQB or not though. In particular, how
> >> does SLUB deal with frees from pages that are not the "current" page? SLQB
> >> does not care what page the object belongs to as long as it's node-local
> >> as the object is just shoved onto a LIFO for maximum hotness.
> >
> > Frees are done directly to the target slab page if they are not to the
> > current active slab page. No centralized locks. Concurrent frees from
> > processors on the same node to multiple other nodes (or different pages
> > on the same node) can occur.
> >
> >> > SLAB deals with it in fallback_alloc(). It scans the nodes in zonelist
> >> > order for free objects of the kmem_cache and then picks up from the
> >> > nearest node. Ugly but it works. SLQB would have to do something similar
> >> > since it also has the per node object bins that SLAB has.
> >> >
> >>
> >> In a real sense, this is what the patch ends up doing. When it fails to
> >> get something locally but sees that the local node is memoryless, it
> >> will check the remote node lists in zonelist order. I think that's
> >> reasonable behaviour but I'm biased because I just want the damn machine
> >> to boot again. What do you think? Pekka, Nick?
> >
> > Look at fallback_alloc() in slab. You can likely copy much of it. It
> > considers memory policies and cpuset constraints.
> 
> Sorry for the delay. I went ahead and merged Mel's patch to make
> things boot on PPC. Fallback policy needs a bit more work as Christoph
> says but I'd really love to have Nick's input on this.
> 
> Mel, do you have a Kconfig patch laying around somewhere to enable
> SLQB on PPC and S390?
> 

It's patch 4 of this series.

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2009-10-05  9:49 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-22 12:54 [PATCH 0/3] Fix SLQB on memoryless configurations V3 Mel Gorman
2009-09-22 12:54 ` Mel Gorman
2009-09-22 12:54 ` [PATCH 1/4] slqb: Do not use DEFINE_PER_CPU for per-node data Mel Gorman
2009-09-22 12:54   ` Mel Gorman
2009-09-22 18:55   ` Pekka Enberg
2009-09-22 18:55     ` Pekka Enberg
2009-09-22 12:54 ` [PATCH 2/4] slqb: Record what node is local to a kmem_cache_cpu Mel Gorman
2009-09-22 12:54   ` Mel Gorman
2009-09-22 13:38   ` Pekka Enberg
2009-09-22 13:38     ` Pekka Enberg
2009-09-22 13:54     ` Mel Gorman
2009-09-22 13:54       ` Mel Gorman
2009-09-22 18:54       ` Pekka Enberg
2009-09-22 18:54         ` Pekka Enberg
2009-09-22 18:56         ` Mel Gorman
2009-09-22 18:56           ` Mel Gorman
2009-09-30 14:41           ` Mel Gorman
2009-09-30 14:41             ` Mel Gorman
2009-09-30 15:06             ` Christoph Lameter
2009-09-30 15:06               ` Christoph Lameter
2009-09-30 22:05               ` Mel Gorman
2009-09-30 22:05                 ` Mel Gorman
2009-09-30 23:45                 ` Christoph Lameter
2009-09-30 23:45                   ` Christoph Lameter
2009-10-01 10:40                   ` Mel Gorman
2009-10-01 10:40                     ` Mel Gorman
2009-10-01 14:32                     ` Christoph Lameter
2009-10-01 14:32                       ` Christoph Lameter
2009-10-01 15:03                       ` Mel Gorman
2009-10-01 15:03                         ` Mel Gorman
2009-10-01 15:03                         ` Christoph Lameter
2009-10-01 15:03                           ` Christoph Lameter
2009-10-01 15:16                           ` Mel Gorman
2009-10-01 15:16                             ` Mel Gorman
2009-10-04 12:06                   ` Pekka Enberg
2009-10-04 12:06                     ` Pekka Enberg
2009-10-05  9:49                     ` Mel Gorman [this message]
2009-10-05  9:49                       ` Mel Gorman
2009-09-22 12:54 ` [PATCH 3/4] slqb: Allow SLQB to be used on PPC and S390 Mel Gorman
2009-09-22 12:54   ` Mel Gorman
2009-09-22 13:21 ` [PATCH 0/3] Fix SLQB on memoryless configurations V3 Mel Gorman
2009-09-22 13:21   ` Mel Gorman

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=20091005094904.GC12681@csn.ul.ie \
    --to=mel@csn.ul.ie \
    --cc=benh@kernel.crashing.org \
    --cc=cl@linux-foundation.org \
    --cc=heiko.carstens@de.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=npiggin@suse.de \
    --cc=penberg@cs.helsinki.fi \
    --cc=sachinp@in.ibm.com \
    --cc=tj@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.