[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YpLhSokkrPrXjNXP@FVFYT0MHHV2J.googleapis.com>
Date: Sun, 29 May 2022 10:58:18 +0800
From: Muchun Song <songmuchun@...edance.com>
To: Matthew Wilcox <willy@...radead.org>
Cc: bh1scw@...il.com, Christoph Lameter <cl@...ux.com>,
Pekka Enberg <penberg@...nel.org>,
David Rientjes <rientjes@...gle.com>,
Joonsoo Kim <iamjoonsoo.kim@....com>,
Andrew Morton <akpm@...ux-foundation.org>,
Vlastimil Babka <vbabka@...e.cz>,
Roman Gushchin <roman.gushchin@...ux.dev>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mm/slub: replace alloc_pages with folio_alloc
On Sat, May 28, 2022 at 05:27:11PM +0100, Matthew Wilcox wrote:
> On Sun, May 29, 2022 at 12:11:58AM +0800, bh1scw@...il.com wrote:
> > From: Fanjun Kong <bh1scw@...il.com>
> >
> > This patch will use folio allocation functions for allocating pages.
>
> That's not actually a good idea. folio_alloc() will do the
> prep_transhuge_page() step which isn't needed for slab.
>
You mean folio_alloc() is dedicated for THP allocation? It is a little
surprise to me. I thought folio_alloc() is just a variant of alloc_page(),
which returns a folio struct instead of a page. Seems like I was wrong.
May I ask what made us decide to do this?
Thanks.
Powered by blists - more mailing lists