fadvise: perform WILLNEED readahead in a workqueue

Applications streaming large files may want to reduce disk spinups and I/O latency by performing large amounts of readahead up front

Quoted 2 lines · On Sat, 15 Dec 2012 00:54:48 +0000 Eric Wong <[email protected]> wrote:

Applications streaming large files may want to reduce disk spinups and I/O latency by performing large amounts of readahead up front

How does it compare benchmark wise with a user thread or using the readahead() call ?

Quoted 8 lines · Alan Cox

Quoted 2 lines · On Sat, 15 Dec 2012 00:54:48 +0000 Eric Wong <[email protected]> wrote:

Applications streaming large files may want to reduce disk spinups and I/O latency by performing large amounts of readahead up front

How does it compare benchmark wise with a user thread or using the readahead() call ?

Very well.

My main concern is for the speed of the initial pread()/read() call after open().

Setting EARLY_EXIT means my test program _exit()s immediately after the first pread(). In my test program (below), I wait for the background thread to become ready before open() so I would not take overhead from pthread_create() into account.

RA=1 uses a pthread + readahead()
Not setting RA uses fadvise (with my patch)

# readahead + pthread.
$ EARLY_EXIT=1 RA=1 time  ./first_read 1G
0.00user 0.05system 0:01.37elapsed 3%CPU (0avgtext+0avgdata 600maxresident)k
0inputs+0outputs (1major+187minor)pagefaults 0swaps

# patched fadvise
$ EARLY_EXIT=1 time ./first_read 1G
0.00user 0.00system 0:00.01elapsed 0%CPU (0avgtext+0avgdata 564maxresident)k
0inputs+0outputs (1major+178minor)pagefaults 0swaps

Quoted 20 lines · Eric Wong

Quoted 8 lines · Alan Cox

Quoted 2 lines · On Sat, 15 Dec 2012 00:54:48 +0000 Eric Wong <[email protected]> wrote:

Applications streaming large files may want to reduce disk spinups and I/O latency by performing large amounts of readahead up front

How does it compare benchmark wise with a user thread or using the readahead() call ?

Very well.

My main concern is for the speed of the initial pread()/read() call after open().

Setting EARLY_EXIT means my test program _exit()s immediately after the first pread(). In my test program (below), I wait for the background thread to become ready before open() so I would not take overhead from pthread_create() into account.

Quoted 2 lines

RA=1 uses a pthread + readahead()
Not setting RA uses fadvise (with my patch)

And if you don't use fadvise/readahead at all?

You're not timing how long the first pread() takes at all. You're timing the entire set of operations, including cloning a thread and for the readahead(2) call and messages to be passed back and forth through the eventfd interface to read the entire file.

Quoted 7 lines · Dave Chinner

Quoted 6 lines · Eric Wong

Quoted 5 lines · Alan Cox

Quoted 2 lines · On Sat, 15 Dec 2012 00:54:48 +0000 Eric Wong <[email protected]> wrote:

Applications streaming large files may want to reduce disk spinups and I/O latency by performing large amounts of readahead up front

This could also be a use case for an audio/video player.

So no, there's no difference that matters between the approaches. But I think doing this in the kernel is easier for userspace users.

Quoted 8 lines · Eric Wong

Quoted 7 lines · Dave Chinner

Quoted 6 lines · Eric Wong

Quoted 5 lines · Alan Cox

Quoted 2 lines · On Sat, 15 Dec 2012 00:54:48 +0000 Eric Wong <[email protected]> wrote:

Applications streaming large files may want to reduce disk spinups and I/O latency by performing large amounts of readahead up front

Quoted 1 line

This could also be a use case for an audio/video player.

Sure, but this can all be handled by a userspace application. If you want to avoid/batch IO to enable longer spindown times, then you have to load the file into RAM somewhere, and you don't need special kernel support for that.

From userspace, I don't know when/if I'm caching too much and possibly

Quoted 2 lines

So no, there's no difference that matters between the approaches. But I think doing this in the kernel is easier for userspace users.

The kernel provides mechanisms for applications to use. You have not mentioned anything new that requires a new kernel mechanism to acheive - you just need to have the knowledge to put the pieces together properly. People have been solving this same problem for the last 20 years without needing to tweak fadvise(). Or even having an fadvise() syscall...

Nothing about low latency IO or streaming IO is simple or easy, and changing how readahead works doesn't change that fact. All it does is change the behaviour of every other application that uses fadvise() to minimise IO latency....

Quoted 12 lines · Dave Chinner

Quoted 10 lines · Eric Wong

Quoted 7 lines · Dave Chinner

Quoted 6 lines · Eric Wong

Quoted 5 lines · Alan Cox

Quoted 2 lines · On Sat, 15 Dec 2012 00:54:48 +0000 Eric Wong <[email protected]> wrote:

Applications streaming large files may want to reduce disk spinups and I/O latency by performing large amounts of readahead up front

This could also be a use case for an audio/video player.

Quoted 4 lines

Sure, but this can all be handled by a userspace application. If you want to avoid/batch IO to enable longer spindown times, then you have to load the file into RAM somewhere, and you don't need special kernel support for that.

From userspace, I don't know when/if I'm caching too much and possibly getting the userspace cache itself swapped out.

Quoted 9 lines

Quoted 2 lines

So no, there's no difference that matters between the approaches. But I think doing this in the kernel is easier for userspace users.

The kernel provides mechanisms for applications to use. You have not mentioned anything new that requires a new kernel mechanism to acheive - you just need to have the knowledge to put the pieces together properly. People have been solving this same problem for the last 20 years without needing to tweak fadvise(). Or even having an fadvise() syscall...

fadvise() is fairly new, and AFAIK few apps use it. Perhaps if it were improved, more people would use it and not have to reinvent the wheel.

Quoted 4 lines

Nothing about low latency IO or streaming IO is simple or easy, and changing how readahead works doesn't change that fact. All it does is change the behaviour of every other application that uses fadvise() to minimise IO latency....

I don't want to introduce regressions, either.

Perhaps if part of the FADV_WILLNEED read-ahead were handled synchronously (maybe 2M?) and humongous large readaheads (like mine) went to the background, that would be a good trade off?

Quoted 10 lines · Eric Wong

Quoted 7 lines · Dave Chinner

Quoted 6 lines · Eric Wong

Quoted 5 lines · Alan Cox

Quoted 2 lines · On Sat, 15 Dec 2012 00:54:48 +0000 Eric Wong <[email protected]> wrote:

Applications streaming large files may want to reduce disk spinups and I/O latency by performing large amounts of readahead up front

This could also be a use case for an audio/video player.

Sure, but this can all be handled by a userspace application. If you want to avoid/batch IO to enable longer spindown times, then you have to load the file into RAM somewhere, and you don't need special kernel support for that.

Quoted 2 lines

So no, there's no difference that matters between the approaches. But I think doing this in the kernel is easier for userspace users.

The kernel provides mechanisms for applications to use. You have not mentioned anything new that requires a new kernel mechanism to acheive - you just need to have the knowledge to put the pieces together properly. People have been solving this same problem for the last 20 years without needing to tweak fadvise(). Or even having an fadvise() syscall...

Nothing about low latency IO or streaming IO is simple or easy, and changing how readahead works doesn't change that fact. All it does is change the behaviour of every other application that uses fadvise() to minimise IO latency....

Applications streaming large files may want to reduce disk spinups and I/O latency by performing large amounts of readahead up front. Applications also tend to read files soon after opening them, so waiting on a slow fadvise may cause unpleasant latency when the application starts reading the file.

As a userspace hacker, I'm sometimes tempted to create a background thread in my app to run readahead(). However, I believe doing this in the kernel will make life easier for other userspace hackers.

Since fadvise makes no guarantees about when (or even if) readahead is performed, this change should not hurt existing applications.

"strace -T" timing on an uncached, one gigabyte file:

Before: fadvise64(3, 0, 0, POSIX_FADV_WILLNEED) = 0 <2.484832>
After: fadvise64(3, 0, 0, POSIX_FADV_WILLNEED) = 0 <0.000061>

Quoted 15 lines · Eric Wong

Applications streaming large files may want to reduce disk spinups and I/O latency by performing large amounts of readahead up front. Applications also tend to read files soon after opening them, so waiting on a slow fadvise may cause unpleasant latency when the application starts reading the file.

As a userspace hacker, I'm sometimes tempted to create a background thread in my app to run readahead(). However, I believe doing this in the kernel will make life easier for other userspace hackers.

Since fadvise makes no guarantees about when (or even if) readahead is performed, this change should not hurt existing applications.

"strace -T" timing on an uncached, one gigabyte file:

Quoted 2 lines

Before: fadvise64(3, 0, 0, POSIX_FADV_WILLNEED) = 0 <2.484832>
After: fadvise64(3, 0, 0, POSIX_FADV_WILLNEED) = 0 <0.000061>

You've basically asked fadvise() to readahead the entire file if it can. That means it is likely to issue enough readahead to fill the IO queue, and that's where all the latency is coming from. If all you are trying to do is reduce the latency of the first read, then only readahead the initial range that you are going to need to read...

Also, Pushing readahead off to a workqueue potentially allows someone to DOS the system because readahead won't ever get throttled in the syscall context...

Perhaps squashing something like the following will work?

Quoted 19 lines · Dave Chinner

Quoted 17 lines · Eric Wong

Applications streaming large files may want to reduce disk spinups and I/O latency by performing large amounts of readahead up front. Applications also tend to read files soon after opening them, so waiting on a slow fadvise may cause unpleasant latency when the application starts reading the file.

As a userspace hacker, I'm sometimes tempted to create a background thread in my app to run readahead(). However, I believe doing this in the kernel will make life easier for other userspace hackers.

Since fadvise makes no guarantees about when (or even if) readahead is performed, this change should not hurt existing applications.

"strace -T" timing on an uncached, one gigabyte file:

Before: fadvise64(3, 0, 0, POSIX_FADV_WILLNEED) = 0 <2.484832>
After: fadvise64(3, 0, 0, POSIX_FADV_WILLNEED) = 0 <0.000061>

Quoted 5 lines

You've basically asked fadvise() to readahead the entire file if it can. That means it is likely to issue enough readahead to fill the IO queue, and that's where all the latency is coming from. If all you are trying to do is reduce the latency of the first read, then only readahead the initial range that you are going to need to read...

Yes, I do want to read the whole file, eventually. So I want to put the file into the page cache ASAP and allow the disk to spin down.

But I also want the first read() to be fast.

Quoted 3 lines

Also, Pushing readahead off to a workqueue potentially allows someone to DOS the system because readahead won't ever get throttled in the syscall context...

Yes, I'm a little worried about this, too. Perhaps squashing something like the following will work?

mm/readahead.c +0 -0

index 56a80a9..51dc58e 100644

Quoted 12 lines · Eric Wong

Quoted 10 lines · Dave Chinner

Quoted 3 lines · Eric Wong

Before: fadvise64(3, 0, 0, POSIX_FADV_WILLNEED) = 0 <2.484832>
After: fadvise64(3, 0, 0, POSIX_FADV_WILLNEED) = 0 <0.000061>

You've basically asked fadvise() to readahead the entire file if it can. That means it is likely to issue enough readahead to fill the IO queue, and that's where all the latency is coming from. If all you are trying to do is reduce the latency of the first read, then only readahead the initial range that you are going to need to read...

Quoted 2 lines

Yes, I do want to read the whole file, eventually. So I want to put the file into the page cache ASAP and allow the disk to spin down.

Issuing readahead is not going to speed up the first read. Either you will spend more time issuing all the readahead, or you block waiting for the first read to complete. And the way you are issuing readahead does not guarantee the entire file is brought into the page cache....

Quoted 1 line

But I also want the first read() to be fast.

You can't have a pony, sorry.

Quoted 15 lines

Quoted 3 lines

Also, Pushing readahead off to a workqueue potentially allows someone to DOS the system because readahead won't ever get throttled in the syscall context...

Yes, I'm a little worried about this, too. Perhaps squashing something like the following will work?

mm/readahead.c +0 -0

index 56a80a9..51dc58e 100644
@@ -246,16 +246,18 @@ void wq_page_cache_readahead(struct address_space *mapping, struct file *filp,
 {
 	struct wq_ra_req *req;
 

mm/readahead.c void wq_page_cache_readahead(struct address_space *mapping, struct file *filp, · line 251

Quoted 3 lines

mm/readahead.c +3 -0

+	nr_to_read = max_sane_readahead(nr_to_read);
+	if (!nr_to_read)
+		goto skip_ra;

You do realise that anything you read ahead will be accounted as inactive pages, so nr_to_read doesn't decrease at all as you fill memory with readahead pages...

mm/readahead.c void wq_page_cache_readahead(struct address_space *mapping, struct file *filp, · line 253

Quoted 1 line

mm/readahead.c +0 -0

 	req = kzalloc(sizeof(*req), GFP_ATOMIC);

GFP_ATOMIC? Really?

In reality, I think you are looking in the wrong place to fix your "first read" latency problem. No matter what you do, there is going to be IO latency on the first read. And readahead doesn't guarantee that the pages are brought into the page cache (ever heard of readahead thrashing?) so the way you are doing your readahead is not going to result in you being able to spin the disk down after issuing a readahead command...

You've really got two problems - minimal initial latency, and reading the file quickly and pinning it in memory until you get around to needing it. The first can't be made faster by using readahead, and the second can not be guaranteed by using readahead.

IOWs, readahead is the wrong tool for solving your problems. Minimal IO latency from the first read will come from just issuing pread() after open(), and ensuring that the file is read quickly and pinned in memory can really only be done by allocating RAM in the application to hold it until it is needed....

Quoted 13 lines · Dave Chinner

Quoted 12 lines · Eric Wong

Quoted 10 lines · Dave Chinner

Quoted 3 lines · Eric Wong

Before: fadvise64(3, 0, 0, POSIX_FADV_WILLNEED) = 0 <2.484832>
After: fadvise64(3, 0, 0, POSIX_FADV_WILLNEED) = 0 <0.000061>

You've basically asked fadvise() to readahead the entire file if it can. That means it is likely to issue enough readahead to fill the IO queue, and that's where all the latency is coming from. If all you are trying to do is reduce the latency of the first read, then only readahead the initial range that you are going to need to read...

Quoted 8 lines

Quoted 2 lines

Yes, I do want to read the whole file, eventually. So I want to put the file into the page cache ASAP and allow the disk to spin down.

Issuing readahead is not going to speed up the first read. Either you will spend more time issuing all the readahead, or you block waiting for the first read to complete. And the way you are issuing readahead does not guarantee the entire file is brought into the page cache....

I'm not relying on readahead to speed up the first read.

By using fadvise/readahead, I want a _best-effort_ attempt to keep the file in cache.

Quoted 3 lines

Quoted 1 line

But I also want the first read() to be fast.

You can't have a pony, sorry.

I want the first read() to happen sooner than it would under current fadvise.

I want "less-bad" initial latency than I was getting.

Quoted 2 lines · Eric Wong

I want the first read() to happen sooner than it would under current fadvise.

You're not listening. You do not need the kernel to be modified to avoid the latency of issuing 1GB of readahead on a file.

You don't need to do readahead before the first read. Nor do you do need to wait for 1GB of readhead to be issued before you do the first read.

You could do readahead *concurrently* with the first read, so the first read only blocks until the readahead of the first part of the file completes. i.e. just do readahead() in a background thread and don't wait for it to complete before doing the first read.

Quoted 11 lines · Eric Wong

Applications streaming large files may want to reduce disk spinups and I/O latency by performing large amounts of readahead up front. Applications also tend to read files soon after opening them, so waiting on a slow fadvise may cause unpleasant latency when the application starts reading the file.

As a userspace hacker, I'm sometimes tempted to create a background thread in my app to run readahead(). However, I believe doing this in the kernel will make life easier for other userspace hackers.

Quoted 8 lines

Since fadvise makes no guarantees about when (or even if) readahead is performed, this change should not hurt existing applications.

"strace -T" timing on an uncached, one gigabyte file:

Before: fadvise64(3, 0, 0, POSIX_FADV_WILLNEED) = 0 <2.484832>
After: fadvise64(3, 0, 0, POSIX_FADV_WILLNEED) = 0 <0.000061>

You've basically asked fadvise() to readahead the entire file if it can. That means it is likely to issue enough readahead to fill the IO queue, and that's where all the latency is coming from. If all you are trying to do is reduce the latency of the first read, then only readahead the initial range that you are going to need to read...

Quoted 5 lines · Eric Wong

Quoted 4 lines

"strace -T" timing on an uncached, one gigabyte file:

Before: fadvise64(3, 0, 0, POSIX_FADV_WILLNEED) = 0 <2.484832>
After: fadvise64(3, 0, 0, POSIX_FADV_WILLNEED) = 0 <0.000061>

It shouldn't take 2 seconds to queue up some async reads. Are you using ext3? The blocks have to be mapped in order to queue the reads, and without ext4 extents, this means the indirect blocks have to be read and can cause fadvise to block.