On Fri, 07 Mar 2014 09:20:39 -0800 Andi Kleen wrote:
> David Rientjes writes:
> >
> > Per-process flags are a scarce resource so we should free them up
> > whenever possible and make them available. We'll be using it shortly for
> > memcg oom reserves.
>
> I'm not convinced TCP_RR is a
David Rientjes writes:
>
> Per-process flags are a scarce resource so we should free them up
> whenever possible and make them available. We'll be using it shortly for
> memcg oom reserves.
I'm not convinced TCP_RR is a meaningfull benchmark for slab.
The shortness seems like an artificial
David Rientjes rient...@google.com writes:
Per-process flags are a scarce resource so we should free them up
whenever possible and make them available. We'll be using it shortly for
memcg oom reserves.
I'm not convinced TCP_RR is a meaningfull benchmark for slab.
The shortness seems like an
On Fri, 07 Mar 2014 09:20:39 -0800 Andi Kleen a...@firstfloor.org wrote:
David Rientjes rient...@google.com writes:
Per-process flags are a scarce resource so we should free them up
whenever possible and make them available. We'll be using it shortly for
memcg oom reserves.
I'm not
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().
Running TCP_RR with netperf-2.4.5
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().
Running TCP_RR with netperf-2.4.5 through
6 matches
Mail list logo
