[PATCH] mm, doc: Update read_ahead_kb for MADV_HUGEPAGE

[PATCH] mm, doc: Update read_ahead_kb for MADV_HUGEPAGE

[Yafang Shao]

MADV_HUGEPAGE is a new addition to readahead with behavior distinct from
normal pages. To prevent confusion, we should update the documentation
accordingly.

Signed-off-by: Yafang Shao <laoar.shao@gmail.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Matthew Wilcox <willy@infradead.org>
---
 Documentation/ABI/stable/sysfs-block | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/ABI/stable/sysfs-block b/Documentation/ABI/stable/sysfs-block
index cea8856f798d..7a820a7d53aa 100644
--- a/Documentation/ABI/stable/sysfs-block
+++ b/Documentation/ABI/stable/sysfs-block
@@ -594,6 +594,9 @@ Description:
 		[RW] Maximum number of kilobytes to read-ahead for filesystems
 		on this block device.
 
+		For MADV_HUGEPAGE, the readahead size may exceed this setting
+		since its granularity is based on the hugepage size.
+
 
 What:		/sys/block/<disk>/queue/rotational
 Date:		January 2009
-- 
2.43.5

Re: [PATCH] mm, doc: Update read_ahead_kb for MADV_HUGEPAGE

[Christoph Hellwig]

On Wed, Nov 13, 2024 at 11:07:11PM +0800, Yafang Shao wrote:
> +		For MADV_HUGEPAGE, the readahead size may exceed this setting
> +		since its granularity is based on the hugepage size.

What does this actually mean?

Also this whole read_ahead_kb has been a massive pain, can we maybe
take a step back and figure out if we still need it at all, and
if yes how we can improve it?  In times where we support page cache
folio sie up to 1M, having a tiny read ahead window is pretty silly,
especially as basically all I/O is done through the "readahead"
interface anyway.

Re: [PATCH] mm, doc: Update read_ahead_kb for MADV_HUGEPAGE

[Yafang Shao]

On Thu, Nov 14, 2024 at 12:36 PM Christoph Hellwig <hch@infradead.org> wrote:
>
> On Wed, Nov 13, 2024 at 11:07:11PM +0800, Yafang Shao wrote:
> > +             For MADV_HUGEPAGE, the readahead size may exceed this setting
> > +             since its granularity is based on the hugepage size.
>
> What does this actually mean?

This means that when read_ahead_kb is set to 128KB, using
MADV_HUGEPAGE will trigger a 4MB readahead, exceeding the specified
limit.

>
> Also this whole read_ahead_kb has been a massive pain, can we maybe
> take a step back and figure out if we still need it at all, and
> if yes how we can improve it?  In times where we support page cache
> folio sie up to 1M, having a tiny read ahead window is pretty silly,
> especially as basically all I/O is done through the "readahead"
> interface anyway.
>

I believe the long-term goal should be to eliminate this interface,
allowing the kernel to automatically adjust the readahead size based
on the device’s bandwidth and latency. However, implementing this
would be challenging. In the meantime, this patch updates
read_ahead_kb to accommodate the newly added MADV_HUGEPAGE in the
readahead path.

-- 
Regards
Yafang