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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Fri, 13 Mar 2009 16:28:05 -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 Fri, 13 Mar 2009, Christoph Lameter wrote:

> > If `memory_slab_hardwall' is set for a cpuset, its tasks will only pull a
> > slab off the partial list that was allocated on an allowed node.  So in my
> > earlier example which segments the machine via cpusets for NUMA locality
> > and then divides those cpusets further for exclusive memory to provide to
> > individual jobs, slab allocations will be constrained within the cpuset of
> > the task that allocated them.  When a job dies, all slab allocations are
> > freed so that no objects remain on the memory allowed to that job and,
> > thus, no partial slabs remain (i.e. there were no object allocations on
> > the job's slabs from disjoint cpusets because of the exclusivity).
> 
> In order to do that you would need to duplicate the partial lists for
> each job and then guarantee that only the job uses objects from these
> partial pages.
> 

Each job is running it its own cpuset with exclusive memory attached to it 
in my example.  With memory_slab_hardwall, we simply don't refill the cpu 
slab with partial slabs that are on s->node[] for nodes that are not 
allowed.  When that job dies, all of its partial slabs will be freed if 
all cpusets within that parent cpuset are memory_slab_hardwall.

This isn't that uncommon of a use case.  The machine is being partitioned, 
depending on their affinity to one another, by its cpus and mems via 
cpusets.  Within those cpusets, which already supply memory locality to 
the cpus that the attached tasks are executing on, we can create 
descendant cpusets to provide memory exclusivity.

I think this is fairly straight forward in my implementation.
--
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/