From: David Rientjes <rientjes@google.com>
To: Paul Menage <menage@google.com>
Cc: Christoph Lameter <cl@linux-foundation.org>,
Pekka Enberg <penberg@cs.helsinki.fi>,
Andrew Morton <akpm@linux-foundation.org>,
Randy Dunlap <randy.dunlap@oracle.com>,
linux-kernel@vger.kernel.org
Subject: Re: [patch 2/2] slub: enforce cpuset restrictions for cpu slabs
Date: Tue, 3 Mar 2009 14:29:31 -0800 (PST) [thread overview]
Message-ID: <alpine.DEB.2.00.0903031401260.29042@chino.kir.corp.google.com> (raw)
In-Reply-To: <6599ad830903031355y3e12dec6n4b7b675d354f8e72@mail.gmail.com>
On Tue, 3 Mar 2009, Paul Menage wrote:
> > Unfortunately, we can't add a slab hardwall flag to the cpuset to
> > configure this behavior since that would require locking to dereference
> > in the fastpath.
> >
>
> I don't think that it would - cgroups and subsystems should be RCU safe.
>
That would help for cpusets that are looking for NUMA optimizations (i.e.
probably long-lived objects with local affinity) but would not ensure
memory isolation from tasks in other exclusive cpusets from allocating on
my slab.
So to address both NUMA and memory isolation, it seems like we'd need to
add a `slab_hardwall' flag that would have to be disabled for both cpusets
(the one hosting the cpu slab and the one allocating an object) to ignore
the hardwall requirement.
That isn't a very clean solution, but is certainly plausible if
Christoph's objection is that in the vast majority of multiple cpuset
systems it is far better to allocate on cpu slabs than for true memory
isolation or the ability to allocate an object on a specific node (for
which we currently have no solution) for affinity.
next prev parent reply other threads:[~2009-03-03 22:30 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-03 4:50 [patch 1/2] cpusets: replace zone allowed functions with node allowed David Rientjes
2009-03-03 4:50 ` [patch 2/2] slub: enforce cpuset restrictions for cpu slabs David Rientjes
2009-03-03 16:47 ` Christoph Lameter
2009-03-03 17:19 ` David Rientjes
2009-03-03 18:46 ` Christoph Lameter
2009-03-03 19:05 ` David Rientjes
2009-03-03 20:14 ` Christoph Lameter
2009-03-03 21:35 ` David Rientjes
2009-03-03 21:55 ` Paul Menage
2009-03-03 22:29 ` David Rientjes [this message]
2009-03-04 0:53 ` Paul Menage
2009-03-04 1:14 ` David Rientjes
2009-03-04 15:23 ` Christoph Lameter
2009-03-04 18:06 ` David Rientjes
2009-03-03 16:36 ` [patch 1/2] cpusets: replace zone allowed functions with node allowed 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=alpine.DEB.2.00.0903031401260.29042@chino.kir.corp.google.com \
--to=rientjes@google.com \
--cc=akpm@linux-foundation.org \
--cc=cl@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=menage@google.com \
--cc=penberg@cs.helsinki.fi \
--cc=randy.dunlap@oracle.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;
as well as URLs for NNTP newsgroup(s).