On Wed, 4 Dec 2013, David Rientjes wrote: > > Right, but it turns out not to matter in practice. As one of the non- > default CONFIG_SLAB users, and PF_MEMPOLICY only does something for > CONFIG_SLAB, this patch tested to not show any degradation for specjbb > which stresses the allocator in terms of throughput: > > with patch: 128761.54 SPECjbb2005 bops > without patch: 127576.65 SPECjbb2005 bops Specjbb? What does Java have to do with this? Can you run the synthetic in kernel slab benchmark. Like this one https://lkml.org/lkml/2009/10/13/459 > These per-process flags are a scarce resource so I don't think > PF_MEMPOLICY warrants a bit when it's not shown to be advantageous in > configurations without mempolicy usage where it's intended to optimize, > especially for a non-default slab allocator. PF_MEMPOLICY was advantageous when Paul Jackson introduced and benchmarked it. SLUB supports mempolicies through allocate_pages but it will allocate all objects out of one slab pages before retrieving another page following the policy. Thats why PF_MEMPOLICY and the other per object handling can be avoided in its fastpath. Thus PF_MEMPOLICY is not that important there. However, SLAB is still the allocator in use for RHEL which puts some importance on still supporting SLAB. -- To unsubscribe from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
