linux-kernel - Re: [patch -mm] cpusets: add memory_slab

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20090309181756.CF66.A69D9226@jp.fujitsu.com>
Date:	Mon,  9 Mar 2009 19:19:16 +0900 (JST)
From:	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
To:	David Rientjes <rientjes@...gle.com>
Cc:	kosaki.motohiro@...fujitsu.com,
	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.

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.



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