| 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: Fri, 28 Sep 2012 13:36:16 -0700 (PDT) From: David Rientjes <rientjes@...gle.com> To: Christoph Lameter <cl@...ux.com> cc: Glauber Costa <glommer@...allels.com>, linux-mm@...ck.org, linux-kernel@...r.kernel.org, Michal Hocko <mhocko@...e.cz>, Pekka Enberg <penberg@...helsinki.fi> Subject: Re: [PATCH] slab: Ignore internal flags in cache creation On Fri, 28 Sep 2012, Christoph Lameter wrote: > > > This means touching another field from critical paths of the allocators. > > > It would increase the cache footprint and therefore reduce performance. > > > > > > > To clarify your statement, you're referring to the mm/slab.c allocation of > > new slab pages and when debugging is enabled as "critical paths", correct? > > We would disagree on that point. > > This is not debugging specific. Flags are also consulted to do RCU > processing and other things. > There is no "critical path" in mm/slab.c that tests CFLGS_OFF_SLAB; the flag itself is used to determine where slab management is done and you certainly wouldn't want to find this for any path that is critical. If you'd like to disagree with that, please show the code and why you consider increasing the cache footprint in that case to be critical to performance. -- 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