From: Yafang Shao <laoar.shao@gmail.com>
To: akpm@linux-foundation.org
Cc: willy@infradead.org, david@redhat.com, oliver.sang@intel.com,
linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
stable@vger.kernel.org
Subject: Re: [PATCH v3] mm/readahead: fix large folio support in async readahead
Date: Sun, 15 Dec 2024 11:10:17 +0800 [thread overview]
Message-ID: <CALOAHbAGOwax+LOo0weyesA=9XfY3hDwUHqunz=24Viu=pjy5g@mail.gmail.com> (raw)
In-Reply-To: <20241206083025.3478-1-laoar.shao@gmail.com>
On Fri, Dec 6, 2024 at 4:31 PM Yafang Shao <laoar.shao@gmail.com> wrote:
>
> When testing large folio support with XFS on our servers, we observed that
> only a few large folios are mapped when reading large files via mmap.
> After a thorough analysis, I identified it was caused by the
> `/sys/block/*/queue/read_ahead_kb` setting. On our test servers, this
> parameter is set to 128KB. After I tune it to 2MB, the large folio can
> work as expected. However, I believe the large folio behavior should not
> be dependent on the value of read_ahead_kb. It would be more robust if
> the kernel can automatically adopt to it.
>
> With /sys/block/*/queue/read_ahead_kb set to 128KB and performing a
> sequential read on a 1GB file using MADV_HUGEPAGE, the differences in
> /proc/meminfo are as follows:
>
> - before this patch
> FileHugePages: 18432 kB
> FilePmdMapped: 4096 kB
>
> - after this patch
> FileHugePages: 1067008 kB
> FilePmdMapped: 1048576 kB
>
> This shows that after applying the patch, the entire 1GB file is mapped to
> huge pages. The stable list is CCed, as without this patch, large folios
> don't function optimally in the readahead path.
>
> It's worth noting that if read_ahead_kb is set to a larger value that
> isn't aligned with huge page sizes (e.g., 4MB + 128KB), it may still fail
> to map to hugepages.
>
> Link: https://lkml.kernel.org/r/20241108141710.9721-1-laoar.shao@gmail.com
> Fixes: 4687fdbb805a ("mm/filemap: Support VM_HUGEPAGE for file mappings")
> Signed-off-by: Yafang Shao <laoar.shao@gmail.com>
> Tested-by: kernel test robot <oliver.sang@intel.com>
> Cc: Matthew Wilcox <willy@infradead.org>
> Cc: David Hildenbrand <david@redhat.com>
> Cc: <stable@vger.kernel.org>
> ---
> mm/readahead.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> Changes:
> v2->v3:
> - Fix the softlockup reported by kernel test robot
> https://lore.kernel.org/linux-fsdevel/202411292300.61edbd37-lkp@intel.com/
>
> v1->v2: https://lore.kernel.org/linux-mm/20241108141710.9721-1-laoar.shao@gmail.com/
> - Drop the alignment (Matthew)
> - Improve commit log (Andrew)
>
> RFC->v1: https://lore.kernel.org/linux-mm/20241106092114.8408-1-laoar.shao@gmail.com/
> - Simplify the code as suggested by Matthew
>
> RFC: https://lore.kernel.org/linux-mm/20241104143015.34684-1-laoar.shao@gmail.com/
>
> diff --git a/mm/readahead.c b/mm/readahead.c
> index 3dc6c7a128dd..1dc3cffd4843 100644
> --- a/mm/readahead.c
> +++ b/mm/readahead.c
> @@ -642,7 +642,11 @@ void page_cache_async_ra(struct readahead_control *ractl,
> 1UL << order);
> if (index == expected) {
> ra->start += ra->size;
> - ra->size = get_next_ra_size(ra, max_pages);
> + /*
> + * In the case of MADV_HUGEPAGE, the actual size might exceed
> + * the readahead window.
> + */
> + ra->size = max(ra->size, get_next_ra_size(ra, max_pages));
> ra->async_size = ra->size;
> goto readit;
> }
> --
> 2.43.5
>
Andrew, could you please drop the previous version and apply this
updated one instead?
--
Regards
Yafang
prev parent reply other threads:[~2024-12-15 3:10 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-06 8:30 Yafang Shao
2024-12-15 3:10 ` Yafang Shao [this message]
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='CALOAHbAGOwax+LOo0weyesA=9XfY3hDwUHqunz=24Viu=pjy5g@mail.gmail.com' \
--to=laoar.shao@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=david@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=oliver.sang@intel.com \
--cc=stable@vger.kernel.org \
--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