It is insane and error-prone to insist on the call sites to check for async
readahead after doing any sync one. I.e. whenever someone do a sync readahead:

                                if (!page)
                                        page_cache_sync_readahead(...);

He must try async readahead, too:

                                page = find_get_page(...);
                                if (PageReadahead(page))
                                        page_cache_async_readahead(...);

The tricky point is that PG_readahead could be set by a sync readahead for the
_current_ newly faulted in page, and the readahead code simply expects one more
callback to handle it. If the caller fails to do so, it will miss the
PG_readahead bits and never able to start an async readahead.

Avoid it by piggy-backing the async part _inside_ the readahead code.

Now if an async readahead should be started immediately after a sync one,
the readahead logic itself will do it. So the following code becomes valid:

                                if (!page)
                                        page_cache_sync_readahead(...);
                                else if (PageReadahead(page))
                                        page_cache_async_readahead(...);

Signed-off-by: Fengguang Wu <[EMAIL PROTECTED]>
---
 mm/readahead.c |    8 ++++++++
 1 file changed, 8 insertions(+)

--- linux-2.6.24-rc5-mm1.orig/mm/readahead.c
+++ linux-2.6.24-rc5-mm1/mm/readahead.c
@@ -402,6 +402,14 @@ ondemand_readahead(struct address_space 
        ra->async_size = ra->size > req_size ? ra->size - req_size : ra->size;
 
 readit:
+       /*
+        * An async readahead should be triggered immediately.
+        * Instead of demanding all call sites to check for async readahead
+        * immediate after a sync one, start the async part now and here.
+        */
+       if (!hit_readahead_marker && ra->size == ra->async_size)
+               ra->size *= 2;
+
        return ra_submit(ra, mapping, filp);
 }
 

-- 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to