Messages in this thread | | | Date | Thu, 5 Dec 2013 19:05:41 +0000 | From | Christoph Lameter <> | Subject | Re: [patch 3/8] mm, mempolicy: remove per-process flag |
| |
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.
| |