[PATCH] readahead.2: don't claim the call blocks until all data has been read

[PATCH] readahead.2: don't claim the call blocks until all data has been read

[Phillip Susi]

The readahead(2) man page was claiming that the call blocks until all
data has been read into the cache.  This is incorrect.

Signed-off-by: Phillip Susi <psusi@ubuntu.com>
---
 man2/readahead.2 | 15 ++++++++++-----
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/man2/readahead.2 b/man2/readahead.2
index 605fa5e..1b0376e 100644
--- a/man2/readahead.2
+++ b/man2/readahead.2
@@ -27,7 +27,7 @@
 .\"
 .TH READAHEAD 2 2013-04-01 "Linux" "Linux Programmer's Manual"
 .SH NAME
-readahead \- perform file readahead into page cache
+readahead \- initiate file readahead into page cache
 .SH SYNOPSIS
 .nf
 .BR "#define _GNU_SOURCE" "             /* See feature_test_macros(7) */"
@@ -37,8 +37,8 @@ readahead \- perform file readahead into page cache
 .fi
 .SH DESCRIPTION
 .BR readahead ()
-populates the page cache with data from a file so that subsequent
-reads from that file will not block on disk I/O.
+initates readahead on a file so that subsequent reads from that file will
+hopefully be satisfied from the cache, and not block on disk I/O.
 The
 .I fd
 argument is a file descriptor identifying the file which is
@@ -57,8 +57,6 @@ equal to
 .IR "(offset+count)" .
 .BR readahead ()
 does not read beyond the end of the file.
-.BR readahead ()
-blocks until the specified data has been read.
 The current file offset of the open file referred to by
 .I fd
 is left unchanged.
@@ -94,6 +92,13 @@ On some 32-bit architectures,
 the calling signature for this system call differs,
 for the reasons described in
 .BR syscall (2).
+
+The call attempts to schedule the reads in the background and return
+immediately, however it may block while reading filesystem metadata
+in order to locate where the blocks requested are.  This occurs frequently
+with ext[234] on large files using indirect blocks instead of extents,
+giving the appearence that the call blocks until the requested data has
+been read.
 .SH SEE ALSO
 .BR lseek (2),
 .BR madvise (2),
-- 
1.8.3.2

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH] readahead.2: don't claim the call blocks until all data has been read

[Michael Kerrisk (man-pages)]

[CC += Past reporters: Corrado Zoccolo, Greg Smith, Zhu Yanhai]

On 03/14/2014 04:54 PM, Phillip Susi wrote:
> The readahead(2) man page was claiming that the call blocks until all
> data has been read into the cache.  This is incorrect.

Phillip, thanks for a good patch that sums things up. I didn't follow
up an earlier patch from Greg Smith, but that patch failed to explain the
behavior we discussed in https://bugzilla.kernel.org/show_bug.cgi?id=54271
where call did sometimes block for a considerable time.

I've applied the patch. Thanks for your efforts and persistence.

I've tweaked your text a bit to make some details clearer (I hope):

       readahead()  initiates  readahead  on a file so that subsequent
       reads from that file will, be satisfied from the cache, and not
       block  on  disk I/O (assuming the readahead was initiated early
       enough and that other activity on the system  did  not  in  the
       meantime flush pages from the cache).

       ...

       readahead()  attempts  to  schedule the reads in the background
       and return immediately.  However, it may block while  it  reads
       the  filesystem metadata needed to locate the requested blocks.
       This occurs frequently with ext[234] on large files using india??
       rect  blocks instead of extents, giving the appearence that the
       call blocks until the requested data has been read.

Okay?

Cheers,

Michael
 
> Signed-off-by: Phillip Susi <psusi@ubuntu.com>
> ---
>  man2/readahead.2 | 15 ++++++++++-----
>  1 file changed, 10 insertions(+), 5 deletions(-)
> 
> diff --git a/man2/readahead.2 b/man2/readahead.2
> index 605fa5e..1b0376e 100644
> --- a/man2/readahead.2
> +++ b/man2/readahead.2
> @@ -27,7 +27,7 @@
>  .\"
>  .TH READAHEAD 2 2013-04-01 "Linux" "Linux Programmer's Manual"
>  .SH NAME
> -readahead \- perform file readahead into page cache
> +readahead \- initiate file readahead into page cache
>  .SH SYNOPSIS
>  .nf
>  .BR "#define _GNU_SOURCE" "             /* See feature_test_macros(7) */"
> @@ -37,8 +37,8 @@ readahead \- perform file readahead into page cache
>  .fi
>  .SH DESCRIPTION
>  .BR readahead ()
> -populates the page cache with data from a file so that subsequent
> -reads from that file will not block on disk I/O.
> +initates readahead on a file so that subsequent reads from that file will
> +hopefully be satisfied from the cache, and not block on disk I/O.
>  The
>  .I fd
>  argument is a file descriptor identifying the file which is
> @@ -57,8 +57,6 @@ equal to
>  .IR "(offset+count)" .
>  .BR readahead ()
>  does not read beyond the end of the file.
> -.BR readahead ()
> -blocks until the specified data has been read.
>  The current file offset of the open file referred to by
>  .I fd
>  is left unchanged.
> @@ -94,6 +92,13 @@ On some 32-bit architectures,
>  the calling signature for this system call differs,
>  for the reasons described in
>  .BR syscall (2).
> +
> +The call attempts to schedule the reads in the background and return
> +immediately, however it may block while reading filesystem metadata
> +in order to locate where the blocks requested are.  This occurs frequently
> +with ext[234] on large files using indirect blocks instead of extents,
> +giving the appearence that the call blocks until the requested data has
> +been read.
>  .SH SEE ALSO
>  .BR lseek (2),
>  .BR madvise (2),
> 


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH] readahead.2: don't claim the call blocks until all data has been read

[Christoph Hellwig]

On Sat, Mar 15, 2014 at 10:05:14AM +0100, Michael Kerrisk (man-pages) wrote:
>        However, it may block while  it  reads
>        the  filesystem metadata needed to locate the requested blocks.
>        This occurs frequently with ext[234] on large files using indi???
>        rect  blocks instead of extents, giving the appearence that the
>        call blocks until the requested data has been read.
> 
> Okay?

The part above is something that should be in the BUGS section.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH] readahead.2: don't claim the call blocks until all data has been read

[Michael Kerrisk (man-pages)]

On Sat, Mar 15, 2014 at 10:24 AM, Christoph Hellwig <hch@infradead.org> wrote:
> On Sat, Mar 15, 2014 at 10:05:14AM +0100, Michael Kerrisk (man-pages) wrote:
>>        However, it may block while  it  reads
>>        the  filesystem metadata needed to locate the requested blocks.
>>        This occurs frequently with ext[234] on large files using indi???
>>        rect  blocks instead of extents, giving the appearence that the
>>        call blocks until the requested data has been read.
>>
>> Okay?
>
> The part above is something that should be in the BUGS section.

Good call. Done. Thanks, Christoph.

Cheers,

Michael




-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH] readahead.2: don't claim the call blocks until all data has been read

[Phillip Susi]

On 03/15/2014 05:05 AM, Michael Kerrisk (man-pages) wrote:
> I've tweaked your text a bit to make some details clearer (I hope):
>
>         readahead()  initiates  readahead  on a file so that subsequent
>         reads from that file will, be satisfied from the cache, and not
>         block  on  disk I/O (assuming the readahead was initiated early
>         enough and that other activity on the system  did  not  in  the
>         meantime flush pages from the cache).

Slight grammatical error there: there's an extra comma in "file will, be".


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH] readahead.2: don't claim the call blocks until all data has been read

[Michael Kerrisk (man-pages)]

On Sat, Mar 15, 2014 at 5:22 PM, Phillip Susi <psusi@ubuntu.com> wrote:
> On 03/15/2014 05:05 AM, Michael Kerrisk (man-pages) wrote:
>>
>> I've tweaked your text a bit to make some details clearer (I hope):
>>
>>         readahead()  initiates  readahead  on a file so that subsequent
>>         reads from that file will, be satisfied from the cache, and not
>>         block  on  disk I/O (assuming the readahead was initiated early
>>         enough and that other activity on the system  did  not  in  the
>>         meantime flush pages from the cache).
>
>
> Slight grammatical error there: there's an extra comma in "file will, be".

Thanks. Fixed.

Otherwise okay, I assume?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH] readahead.2: don't claim the call blocks until all data has been read

[Phillip Susi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 03/15/2014 12:25 PM, Michael Kerrisk (man-pages) wrote:
>> Slight grammatical error there: there's an extra comma in "file
>> will, be".
> 
> Thanks. Fixed.
> 
> Otherwise okay, I assume?

Yep.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCgAGBQJTJOGXAAoJEI5FoCIzSKrwWL0IAJR+RDiqPUUMuRQyT+ZUICnX
5MToU3EnyEpwY37HXHIAcQv6cYwo7Z7gP7EQseChIcozzQO/xCulrH/41FyuxRt1
ci1ow/XeydhsWQ0nKpY8ox5DWfErV0csUYO+dazrKRKGnAPXQv0+Bx2DPP9mPKuJ
q9FBMP+FIFuVQW6o0VxOxQIW1lx/oYI+a5q+P91pd4fDcI0igKFNn6x5SvoaDbLI
HwA6VTmySs2BVwN3w3BK6fadWXnqd6xJUMGN0OdsqiecZGW+qgB6EdyrY9xPOjgX
ixFCpcj67OGPZY+sEAdO2T+QxNytnhhP/5Z/F7kkiu/6mKoRm/uQSdSnDZr4aPU=
=5KCU
-----END PGP SIGNATURE-----

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>