[RFC] mm/readahead: Fix repeat initial_readahead

Commit Message

Zhang Peng June 18, 2024, 11:49 a.m. UTC

From: bruzzhang <[e-mail]>

Now, if read from start of file, readahead
state will be repeatly initialized when
first time async readahead after sync one.
This case likes:

sequence read
page_cache_sync_readahead()
  --> ondemand_readahead() <-- initial ra
  --> folio ready <-- order=2, readahead flags
folio_test_readahead(folio)
filemap_readahead() <-- async readahead
 --> ondemand_readahead() <-- initial ra again

The second initialization of ra seems a
mistake, and right ra window
(start, size, async_size) should be (4,8,8)
instead of (0,4,3) after async readahead.

What's more, this patch can improve sequence
read greatly, the result of test as following:

case name             upstream    upstream+fix  speedup
----------            --------    ------------  --------
randread-4k-sync      48981.00    48948.0000    -0.0674%
seqread-4k-sync       1162630.00  1334915.00    14.8186%
randread-4k-libaio    47561.00    49910.00      4.9389%
seqread-4k-libaio     1058526.00  1257134.00    18.7627%
seqread-1024k-libaio  1365866.00  1411463.00    3.3383%

Signed-off-by: bruzzhang <[e-mail]>
Signed-off-by: Rongwei Wang <[e-mail]>
Signed-off-by: Vern Hao <[e-mail]>
---
 mm/readahead.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

zippermonkey June 25, 2024, 6:28 a.m. UTC | #1

To illustrate this problem, I created the following example:


Assuming that the process reads sequentially from the beginning of the 
file and
calls the `page_cache_sync_readahead` function. In this sync readahead 
function,
since the index is 0, it will proceed to `initial_readahead` and initialize
`ra_state`. It allocates a folio with an order of 2 and marks it as 
PG_readahead.
Next, because` (folio_test_readahead(folio))` is true, the 
page_cache_async_ra
function is called, which causes the `ra_state` to be initialized again.

Jan Kara June 25, 2024, 10:36 a.m. UTC | #2

On Tue 25-06-24 14:28:34, zippermonkey wrote:
> To illustrate this problem, I created the following example:
> 
> Assuming that the process reads sequentially from the beginning of the file
> and
> calls the `page_cache_sync_readahead` function. In this sync readahead
> function,
> since the index is 0, it will proceed to `initial_readahead` and initialize
> `ra_state`. It allocates a folio with an order of 2 and marks it as
> PG_readahead.
> Next, because` (folio_test_readahead(folio))` is true, the
> page_cache_async_ra
> function is called, which causes the `ra_state` to be initialized again.

Good spotting guys! There are actually more problems in the readahead code.
I have just pushed out a patch series [1] addressing several issues that
should also address the problem you've found. Can you please test whether
it provides a similar speedup as your fix (sorry, I forgot to CC you on the
series)? Thanks!

[1] https://lore.kernel.org/[e-mail]

								Honza

Patch

diff --git a/mm/readahead.c b/mm/readahead.c
index c1b23989d..498708b4b 100644
--- a/mm/readahead.c
+++ b/mm/readahead.c
@@ -571,7 +571,7 @@  static void ondemand_readahead(struct readahead_control *ractl,
 	/*
 	 * start of file
 	 */
-	if (!index)
+	if (!folio && !index)
 		goto initial_readahead;
 
 	/*