On Thu, 5 Dec 2013, David Rientjes wrote:
> We actually carry that in our production kernel and have updated it to
> build on 3.11, I'll run it and netperf TCP_RR as well, thanks.
If you get around it then please post the updated version. Maybe we can
get that merged at some point. Keeps floating
On Thu, 5 Dec 2013, Christoph Lameter wrote:
> 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
>
We actually carry that in our production kernel and have updated it to
build on 3.11, I'll
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 term
On Wed, 4 Dec 2013, Christoph Lameter wrote:
> > PF_MEMPOLICY is an unnecessary optimization for CONFIG_SLAB users.
> > There's no significant performance degradation to checking
> > current->mempolicy rather than current->flags & PF_MEMPOLICY in the
> > allocation path, especially since this is c
On Tue, 3 Dec 2013, David Rientjes wrote:
> PF_MEMPOLICY is an unnecessary optimization for CONFIG_SLAB users.
> There's no significant performance degradation to checking
> current->mempolicy rather than current->flags & PF_MEMPOLICY in the
> allocation path, especially since this is considered u
PF_MEMPOLICY is an unnecessary optimization for CONFIG_SLAB users.
There's no significant performance degradation to checking
current->mempolicy rather than current->flags & PF_MEMPOLICY in the
allocation path, especially since this is considered unlikely().
Per-process flags are a scarce resource
6 matches
Mail list logo
