Re: [patch -mm] cpusets: add memory_slab_hardwall flag

[KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>]

> 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.

My question mean, Why anyone need isolation?
your patch insert new branch into hotpath.
then, it makes slower hotpath a abit although a user don't use this feature.

typically, slab cache don't need strict node binding because
inode/dentry touched from multiple cpus.

In addition, on large numa systems, slab cache is relatively small
than page cache. then this feature's improvement seems relatively small too.

if you have strongly reason, I don't oppose this proposal.
but I don't think your explanation is enough reasonable reason.


btw, have you seen "immediate values" patch series? I think it
can become make the patch zero cost for non-cpuset user.
after that patch merging, I don't oppose this patch although
your reason isn't so much.