linux-kernel - Re: [PATCH] slab: Ignore internal flags in cache creation

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.00.1209281332460.21335@chino.kir.corp.google.com>
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/