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

[David Rientjes]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/