[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.00.0903090206010.24605@chino.kir.corp.google.com>
Date: Mon, 9 Mar 2009 02:12:21 -0700 (PDT)
From: David Rientjes <rientjes@...gle.com>
To: KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
cc: Andrew Morton <akpm@...ux-foundation.org>,
Christoph Lameter <cl@...ux-foundation.org>,
Pekka Enberg <penberg@...helsinki.fi>,
Matt Mackall <mpm@...enic.com>,
Paul Menage <menage@...gle.com>,
Randy Dunlap <randy.dunlap@...cle.com>,
linux-kernel@...r.kernel.org
Subject: Re: [patch -mm] cpusets: add memory_slab_hardwall flag
On Mon, 9 Mar 2009, KOSAKI Motohiro wrote:
> Hmmm,
> this description only explay how to implement this.
> but no explain why this patch is useful.
>
> Could you please who and why need it?
>
The change to Documentation/cgroups/cpusets.txt should have explained it.
This is for two cases: true memory isolation (now including slab
allocations at the object level) and NUMA optimizations.
Prior to this change, it was possible for slabs to be allocated in a
cpuset while its objects were largely consumed by disjoint cpusets. We
can fix that by only allocating objects from slabs that are found on
current->mems_allowed. While this incurs a performance penalty, some
users may find that true isolation outweighs the cache optimizations.
It is also helpful for long-lived objects that require NUMA affinity to a
certain cpu or group of cpus. That is, after all, the reasoning behind
cpusets in the first place. If slab objects were all allocated from a
node with remote affinity to the cpus that will be addressing it, it
negates a significant advantage that cpusets provides to the user.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists