linux-kernel - Re: [patch -mm v2] 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 for Android: free password hash cracker in your pocket

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

Date:	Tue, 10 Mar 2009 14:24:35 -0700 (PDT)
From:	David Rientjes <rientjes@...gle.com>
To:	Christoph Lameter <cl@...ux-foundation.org>
cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Pekka Enberg <penberg@...helsinki.fi>,
	Matt Mackall <mpm@...enic.com>,
	Paul Menage <menage@...gle.com>,
	Randy Dunlap <randy.dunlap@...cle.com>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [patch -mm v2] cpusets: add memory_slab_hardwall flag

On Tue, 10 Mar 2009, Christoph Lameter wrote:

> We already have PF_SPREAD_PAGE PF_SPREAD_SLAB and PF_MEMPOLICY.
> PF_MEMPOLICY in slab can have the same role as PF_SLAB_HARDWALL. It
> attempts what you describe. One the one hand you duplicate functionality
> that is already there and on the other you want to put code in the hot
> paths that we have intentionally avoided for ages.
> 

For slab, PF_MEMPOLICY is a viable alternative for the functionality that 
is being added with this patch.  The difference is that it only is 
enforced when the allocating task is a member of that cpuset and does not 
require the overhead of scanning the MPOL_BIND zonelist for every 
allocation to determine whwther a node is acceptable.

For slub, there is no current alternative to memory_slab_hardwall.

> The description is not accurate. This feature is only useful if someone
> comes up with a crummy cpuset definition in which a processor is a member
> of multiple cpusets and thus the per cpu queues of multiple subsystems get
> objects depending on which cpuset is active.
> 

Cpusets are hierarchical, so it is quite possible that a parent cpuset 
will include a group of cpus that has affinity to a specific group of 
mems.  This isolates that cpuset and all of its children for NUMA 
optimiziations.  Within that, there can be several descendant cpusets that 
include disjoint subsets of mems to isolate the memory that can be used 
for specific jobs.
--
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/