From: David Hildenbrand <david@redhat.com>
To: Joanne Koong <joannelkoong@gmail.com>
Cc: miklos@szeredi.hu, linux-fsdevel@vger.kernel.org,
jlayton@kernel.org, jefflexu@linux.alibaba.com,
josef@toxicpanda.com, bernd.schubert@fastmail.fm,
willy@infradead.org, kernel-team@meta.com
Subject: Re: [PATCH v5 10/11] fuse: optimize direct io large folios processing
Date: Tue, 8 Jul 2025 18:05:23 +0200 [thread overview]
Message-ID: <9a9cea9e-82e7-4411-8927-8ac911b2eb06@redhat.com> (raw)
In-Reply-To: <CAJnrk1bTe88hy4XSkj1RSC4r+oA=VZ-=jKymt7uoB1q75KZCYg@mail.gmail.com>
On 08.07.25 01:27, Joanne Koong wrote:
> On Fri, Jul 4, 2025 at 3:24 AM David Hildenbrand <david@redhat.com> wrote:
>>
>> On 26.04.25 02:08, Joanne Koong wrote:
>>> Optimize processing folios larger than one page size for the direct io
>>> case. If contiguous pages are part of the same folio, collate the
>>> processing instead of processing each page in the folio separately.
>>>
>>> Signed-off-by: Joanne Koong <joannelkoong@gmail.com>
>>> Reviewed-by: Jeff Layton <jlayton@kernel.org>
>>> ---
>>> fs/fuse/file.c | 55 +++++++++++++++++++++++++++++++++++++-------------
>>> 1 file changed, 41 insertions(+), 14 deletions(-)
>>>
>>> diff --git a/fs/fuse/file.c b/fs/fuse/file.c
>>> index 9a31f2a516b9..61eaec1c993b 100644
>>> --- a/fs/fuse/file.c
>>> +++ b/fs/fuse/file.c
>>> @@ -1490,7 +1490,8 @@ static int fuse_get_user_pages(struct fuse_args_pages *ap, struct iov_iter *ii,
>>> }
>>>
>>> while (nbytes < *nbytesp && nr_pages < max_pages) {
>>> - unsigned nfolios, i;
>>> + struct folio *prev_folio = NULL;
>>> + unsigned npages, i;
>>> size_t start;
>>>
>>> ret = iov_iter_extract_pages(ii, &pages,
>>> @@ -1502,23 +1503,49 @@ static int fuse_get_user_pages(struct fuse_args_pages *ap, struct iov_iter *ii,
>>>
>>> nbytes += ret;
>>>
>>> - nfolios = DIV_ROUND_UP(ret + start, PAGE_SIZE);
>>> + npages = DIV_ROUND_UP(ret + start, PAGE_SIZE);
>>>
>>> - for (i = 0; i < nfolios; i++) {
>>> - struct folio *folio = page_folio(pages[i]);
>>> - unsigned int offset = start +
>>> - (folio_page_idx(folio, pages[i]) << PAGE_SHIFT);
>>> - unsigned int len = min_t(unsigned int, ret, PAGE_SIZE - start);
>>> + /*
>>> + * We must check each extracted page. We can't assume every page
>>> + * in a large folio is used. For example, userspace may mmap() a
>>> + * file PROT_WRITE, MAP_PRIVATE, and then store to the middle of
>>> + * a large folio, in which case the extracted pages could be
>>> + *
>>> + * folio A page 0
>>> + * folio A page 1
>>> + * folio B page 0
>>> + * folio A page 3
>>> + *
>>> + * where folio A belongs to the file and folio B is an anonymous
>>> + * COW page.
>>> + */
>>> + for (i = 0; i < npages && ret; i++) {
>>> + struct folio *folio;
>>> + unsigned int offset;
>>> + unsigned int len;
>>> +
>>> + WARN_ON(!pages[i]);
>>> + folio = page_folio(pages[i]);
>>> +
>>> + len = min_t(unsigned int, ret, PAGE_SIZE - start);
>>> +
>>> + if (folio == prev_folio && pages[i] != pages[i - 1]) {
>>
>> I don't really understand the "pages[i] != pages[i - 1]" part.
>>
>> Why would you have to equal page pointers in there?
>>
>
> The pages extracted are user pages from a userspace iovec. AFAICT,
> there's the possibility, eg if userspace mmaps() the file with
> copy-on-write, that the same physical page could back multiple
> contiguous virtual addresses.
Yes, I but I was rather curious why that would be a condition we are
checking. It's quite the ... corner case :)
>
>>
>> Something that might be simpler to understand and implement would be using
>>
>> num_pages_contiguous()
>>
>> from
>>
>> https://lore.kernel.org/all/20250704062602.33500-2-lizhe.67@bytedance.com/T/#u
>>
>> and then just making sure that we don't exceed the current folio, if we
>> ever get contiguous pages that cross a folio.
>
> Thanks for the link. I think here it's common that the pages array
> would hold pages from multiple different folios, so maybe a new helper
> num_pages_contiguous_folio() would be useful to return back the number
> of contiguous pages that are within the scope of the same folio.
Yes, something like that can be useful.
--
Cheers,
David / dhildenb
next prev parent reply other threads:[~2025-07-08 16:05 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-26 0:08 [PATCH v5 00/11] fuse: support large folios Joanne Koong
2025-04-26 0:08 ` [PATCH v5 01/11] fuse: support copying " Joanne Koong
2025-05-04 18:05 ` Bernd Schubert
2025-04-26 0:08 ` [PATCH v5 02/11] fuse: support large folios for retrieves Joanne Koong
2025-05-04 18:07 ` Bernd Schubert
2025-04-26 0:08 ` [PATCH v5 03/11] fuse: refactor fuse_fill_write_pages() Joanne Koong
2025-04-26 19:25 ` kernel test robot
2025-04-28 5:32 ` Dan Carpenter
2025-04-28 22:10 ` Joanne Koong
2025-05-04 18:08 ` Bernd Schubert
2025-04-26 0:08 ` [PATCH v5 04/11] fuse: support large folios for writethrough writes Joanne Koong
2025-05-04 18:40 ` Bernd Schubert
2025-05-05 21:36 ` Joanne Koong
2025-04-26 0:08 ` [PATCH v5 05/11] fuse: support large folios for folio reads Joanne Koong
2025-05-04 18:58 ` Bernd Schubert
2025-04-26 0:08 ` [PATCH v5 06/11] fuse: support large folios for symlinks Joanne Koong
2025-05-04 19:04 ` Bernd Schubert
2025-04-26 0:08 ` [PATCH v5 07/11] fuse: support large folios for stores Joanne Koong
2025-04-26 0:08 ` [PATCH v5 08/11] fuse: support large folios for queued writes Joanne Koong
2025-05-04 19:08 ` Bernd Schubert
2025-04-26 0:08 ` [PATCH v5 09/11] fuse: support large folios for readahead Joanne Koong
2025-05-04 19:13 ` Bernd Schubert
2025-05-05 14:40 ` Darrick J. Wong
2025-05-05 15:23 ` Bernd Schubert
2025-05-05 22:05 ` Joanne Koong
2025-04-26 0:08 ` [PATCH v5 10/11] fuse: optimize direct io large folios processing Joanne Koong
2025-05-04 19:15 ` Bernd Schubert
2025-07-04 10:24 ` David Hildenbrand
2025-07-07 23:27 ` Joanne Koong
2025-07-08 16:05 ` David Hildenbrand [this message]
2025-07-08 23:14 ` Joanne Koong
2025-04-26 0:08 ` [PATCH v5 11/11] fuse: support large folios for writeback Joanne Koong
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=9a9cea9e-82e7-4411-8927-8ac911b2eb06@redhat.com \
--to=david@redhat.com \
--cc=bernd.schubert@fastmail.fm \
--cc=jefflexu@linux.alibaba.com \
--cc=jlayton@kernel.org \
--cc=joannelkoong@gmail.com \
--cc=josef@toxicpanda.com \
--cc=kernel-team@meta.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=miklos@szeredi.hu \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.