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: <alpine.DEB.2.00.0903092112100.26081@chino.kir.corp.google.com>
Date:	Mon, 9 Mar 2009 21:26:11 -0700 (PDT)
From:	David Rientjes <rientjes@...gle.com>
To:	Matt Mackall <mpm@...enic.com>
cc:	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Christoph Lameter <cl@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Pekka Enberg <penberg@...helsinki.fi>,
	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, Matt Mackall wrote:

> But we are still extremely sensitive to adding potential branches to one
> of the most important fast-paths in the kernel, especially for a feature
> with a fairly narrow use case. We've invested an awful lot of time into
> micro-optimizing SLAB (by rewriting it as SLUB/SLQB) so any steps
> backward at this stage are cause for concern. Also, remember 99%+ of
> users will never care about this feature.
> 

My latest proposal simply checks for !(current->flags & PF_SLAB_HARDWALL) 
before determining whether the set of allowable nodes needs to be checked.  
For slub, this is in addition to the prexisting logic that checks whether 
the object can be from any node (node == -1) in slab_alloc() or the cpu 
slab is from the node requested for kmalloc_node() users for CONFIG_NUMA 
kernels.

You could argue that, in the slub example, check_node() should do this:

	static inline int check_node(struct kmem_cache_cpu *c, int node,
				     gfp_t flags)
	{
	#ifdef CONFIG_NUMA
		if (node != -1 && c->node != node)
			return 0;
		if (likely(!(current->flags & PF_SLAB_HARDWALL)))
			return 1;
	#endif
		return current_cpuset_object_allowed(node, flags);
	}

Although this would penalize the case where current's cpuset has 
memory_slab_hardwall enabled, yet the cpu slab is still allowed because it 
originated from current->mems_allowed.

If checking for the PF_SLAB_HARDWALL bit in current->flags really is 
unacceptable in my latest proposal, then a viable solution probably 
doesn't exist for such workloads that want hardwall object allocations.
--
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/