From: David Hildenbrand <david@redhat.com>
To: Alistair Popple <apopple@nvidia.com>
Cc: linux-mm@kvack.org, linux-fsdevel@vger.kernel.org,
nvdimm@lists.linux.dev,
Alison Schofield <alison.schofield@intel.com>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Christian Brauner <brauner@kernel.org>, Jan Kara <jack@suse.cz>,
Dan Williams <dan.j.williams@intel.com>,
Matthew Wilcox <willy@infradead.org>,
Andrew Morton <akpm@linux-foundation.org>,
Alistair Popple <apopple@nvidia.com>,
Christoph Hellwig <hch@infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v1] fs/dax: fix folio splitting issue by resetting old folio order + _nr_pages
Date: Fri, 11 Apr 2025 10:37:17 +0200 [thread overview]
Message-ID: <6e1a9ad5-c1e1-4f04-af67-cfc05246acbc@redhat.com> (raw)
In-Reply-To: <qpfgzrstgtyus3jkzrdpwxg2ex7aounhwca65bxwlqxws2drhk@op362gbaestm>
(adding CC list again, because I assume it was dropped by accident)
>> diff --git a/fs/dax.c b/fs/dax.c
>> index af5045b0f476e..676303419e9e8 100644
>> --- a/fs/dax.c
>> +++ b/fs/dax.c
>> @@ -396,6 +396,7 @@ static inline unsigned long dax_folio_put(struct folio *folio)
>> order = folio_order(folio);
>> if (!order)
>> return 0;
>> + folio_reset_order(folio);
>
> Wouldn't it be better to also move the loop below into this function? The intent
> of this loop was to reinitialise the small folios after splitting which is what
> I think this helper should be doing.
As the function does nothing on small folios (as documented), I think
this is good enough for now.
Once we decouple folio from page, this code will likely have to change
either way ...
The first large folio will become a small folio (so resetting kind-of
makes sense), but the other small folios would have to allocate a new
"struct folio" for small folios.
>
>> for (i = 0; i < (1UL << order); i++) {
>> struct dev_pagemap *pgmap = page_pgmap(&folio->page);
>> diff --git a/include/linux/mm.h b/include/linux/mm.h
>> index b7f13f087954b..bf55206935c46 100644
>> --- a/include/linux/mm.h
>> +++ b/include/linux/mm.h
>> @@ -1218,6 +1218,23 @@ static inline unsigned int folio_order(const struct folio *folio)
>> return folio_large_order(folio);
>> }
>>
>> +/**
>> + * folio_reset_order - Reset the folio order and derived _nr_pages
>> + * @folio: The folio.
>> + *
>> + * Reset the order and derived _nr_pages to 0. Must only be used in the
>> + * process of splitting large folios.
>> + */
>> +static inline void folio_reset_order(struct folio *folio)
>> +{
>> + if (WARN_ON_ONCE(!folio_test_large(folio)))
>> + return;
>> + folio->_flags_1 &= ~0xffUL;
>> +#ifdef NR_PAGES_IN_LARGE_FOLIO
>> + folio->_nr_pages = 0;
>> +#endif
>> +}
>> +
I'm still not sure if this splitting code in fs/dax.c is more similar to
THP splitting or to "splitting when freeing in the buddy". I think it's
something in between: we want small folios, but the new folios are
essentially free.
Likely, to be future-proof, we should also look into doing
folio->_flags_1 &= ~PAGE_FLAGS_SECOND;
Or alternatively (better?)
new_folio->flags &= ~PAGE_FLAGS_CHECK_AT_PREP;
... but that problem will go away once we decouple page from folio (see
above), so I'm not sure if we should really do that at this point unless
there is an issue.
--
Cheers,
David / dhildenb
next prev parent reply other threads:[~2025-04-11 8:37 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-10 9:10 David Hildenbrand
2025-04-10 19:12 ` Alison Schofield
2025-04-17 3:44 ` Darrick J. Wong
2025-04-17 18:01 ` Dan Williams
2025-04-17 22:59 ` Andrew Morton
2025-04-10 20:15 ` Dan Williams
2025-04-10 20:23 ` Matthew Wilcox
2025-04-10 20:46 ` Dan Williams
2025-04-10 21:54 ` Matthew Wilcox
2025-04-11 8:28 ` David Hildenbrand
[not found] ` <qpfgzrstgtyus3jkzrdpwxg2ex7aounhwca65bxwlqxws2drhk@op362gbaestm>
2025-04-11 8:37 ` David Hildenbrand [this message]
2025-04-14 0:32 ` Alistair Popple
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=6e1a9ad5-c1e1-4f04-af67-cfc05246acbc@redhat.com \
--to=david@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=alison.schofield@intel.com \
--cc=apopple@nvidia.com \
--cc=brauner@kernel.org \
--cc=dan.j.williams@intel.com \
--cc=hch@infradead.org \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=nvdimm@lists.linux.dev \
--cc=viro@zeniv.linux.org.uk \
--cc=willy@infradead.org \
/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
all inboxes | Powered by JetHome®