lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 5 Dec 2013 19:05:41 +0000 From: Christoph Lameter <cl@...ux.com> To: David Rientjes <rientjes@...gle.com> cc: Andrew Morton <akpm@...ux-foundation.org>, Michal Hocko <mhocko@...e.cz>, KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>, Johannes Weiner <hannes@...xchg.org>, Mel Gorman <mgorman@...e.de>, Rik van Riel <riel@...hat.com>, Pekka Enberg <penberg@...nel.org>, linux-kernel@...r.kernel.org, linux-mm@...ck.org, cgroups@...r.kernel.org 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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists