[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180412142718.GA20398@bombadil.infradead.org>
Date: Thu, 12 Apr 2018 07:27:18 -0700
From: Matthew Wilcox <willy@...radead.org>
To: Christopher Lameter <cl@...ux.com>
Cc: linux-mm@...ck.org, Matthew Wilcox <mawilcox@...rosoft.com>,
Pekka Enberg <penberg@...nel.org>,
David Rientjes <rientjes@...gle.com>,
Joonsoo Kim <iamjoonsoo.kim@....com>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org, Jan Kara <jack@...e.cz>,
Jeff Layton <jlayton@...hat.com>,
Mel Gorman <mgorman@...hsingularity.net>
Subject: Re: [PATCH v2 2/2] slab: __GFP_ZERO is incompatible with a
constructor
On Thu, Apr 12, 2018 at 09:10:23AM -0500, Christopher Lameter wrote:
> On Wed, 11 Apr 2018, Matthew Wilcox wrote:
> > I don't see how that works ... can you explain a little more?
>
> c->freelist is NULL and thus ___slab_alloc (slowpath) is called.
> ___slab_alloc populates c->freelist and gets the new object pointer.
>
> if debugging is on then c->freelist is set to NULL at the end of
> ___slab_alloc because deactivate_slab() is called.
>
> Thus the next invocation of the fastpath will find that c->freelist is
> NULL and go to the slowpath. ...
_ah_. I hadn't figured out that c->page was always NULL in the debugging
case too, so ___slab_alloc() always hits the 'new_slab' case. Thanks!
Powered by blists - more mailing lists