From: Matthew Wilcox <willy@infradead.org>
To: Muchun Song <songmuchun@bytedance.com>
Cc: bh1scw@gmail.com, Christoph Lameter <cl@linux.com>,
Pekka Enberg <penberg@kernel.org>,
David Rientjes <rientjes@google.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Andrew Morton <akpm@linux-foundation.org>,
Vlastimil Babka <vbabka@suse.cz>,
Roman Gushchin <roman.gushchin@linux.dev>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm/slub: replace alloc_pages with folio_alloc
Date: Sun, 29 May 2022 04:31:07 +0100 [thread overview]
Message-ID: <YpLo+4U8k+OLTmz9@casper.infradead.org> (raw)
In-Reply-To: <YpLhSokkrPrXjNXP@FVFYT0MHHV2J.googleapis.com>
On Sun, May 29, 2022 at 10:58:18AM +0800, Muchun Song wrote:
> On Sat, May 28, 2022 at 05:27:11PM +0100, Matthew Wilcox wrote:
> > On Sun, May 29, 2022 at 12:11:58AM +0800, bh1scw@gmail.com wrote:
> > > From: Fanjun Kong <bh1scw@gmail.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?
Yeah, the naming isn't great here. The problem didn't really occur
to me until I saw this patch, and I don't have a good solution yet.
We're in the middle of a transition, but the transition is likely to
take years and I don't think we necessarily have the final form of the
transition fully agreed to or understood, so we should come up with
something better for the transition.
Ignoring the naming here, memory allocated to filesystems can be split,
but the split can fail, so they need the page-deferred-list and the
DTOR. Memory allocated to slab cannot be split, so initialising the
page-deferred-list is a waste of time.
The end-goal is to split apart allocating the memory from allocating
its memory descriptor (which I like to call memdesc). So for filesystem
folios, we'd call slab to allocate a struct folio and then tell the
buddy allocator "here is the memdesc of type folio, allocate
me 2^n pages and make pfn_to_memdesc return this memdesc for each of
the 2^n pages in it".
In this end-goal, slab would also allocate a struct slab (... there's
a recursion problem here which has a solution ...), and then allocate
2^n pages. But until we're ready to shrink struct page down to one
or two words, doing this is just a waste of memory and time.
So I still don't have a good solution to receiving patches like this
other than maybe adding a comment like
/* Do not change this to allocate a folio */
which will be ignored.
next prev parent reply other threads:[~2022-05-29 3:31 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-28 16:11 [PATCH] mm/slub: replace alloc_pages with folio_alloc bh1scw
2022-05-28 16:27 ` Matthew Wilcox
2022-05-29 2:58 ` Muchun Song
2022-05-29 3:31 ` Matthew Wilcox [this message]
2022-05-30 0:55 ` Matthew Wilcox
2022-05-30 4:10 ` [mm/slub] 4c863a2fd7: WARNING:at_mm/page_alloc.c:#__alloc_pages kernel test robot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YpLo+4U8k+OLTmz9@casper.infradead.org \
--to=willy@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=bh1scw@gmail.com \
--cc=cl@linux.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
--cc=roman.gushchin@linux.dev \
--cc=songmuchun@bytedance.com \
--cc=vbabka@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).