Improving readahead

Posted Feb 6, 2010 3:03 UTC (Sat) by giraffedata (guest, #1954)
In reply to: Improving readahead by corbet
Parent article: Improving readahead

I guess I wasn't clear, or I totally misparsed your sentence:

When readahead works well, it can significantly improve the performance of I/O bound applications by avoiding the need for those applications to wait for data and by increasing I/O transfer size

You say readahead improves application performance by doing A and B. B is increasing transfer size, so I assumed A is something separate. Not having to wait for I/O isn't a reason for higher performance; it's essentially the definition (like saying a car arrives at its destination sooner because it goes faster). So I asked myself what wait-reducing effect you were referring to, and I figured you meant that when an application does processing while the I/O is going on, when it gets around to requesting the I/O, there's no waiting left to do. Well, an clearer way to explain that performance-improving effect is to say the application can overlap processing and I/O.

Note that this effect isn't present if the application doesn't have any processing to do. Readahead won't help that application -- won't reduce the wait for I/O -- except by one of the other effects. That's obvious when you refer to the overlap, but not when you just say it reduces wait time.

So much for the language analysis. The key thing for people to remember about readhead is that it improves application performance by reducing waiting time for I/O in these three ways:

the application can overlap processing and I/O without explicit threading.
the system can do larger I/Os.
the system can order I/Os better.

to post comments

Improving readahead

Posted Feb 7, 2010 2:19 UTC (Sun) by dmag (guest, #17775) [Link] (1 responses)

>> it can significantly improve the performance of I/O bound applications by avoiding the need for those applications to wait for data

> Note that this effect isn't present if the application doesn't have any processing to do.

Nope. Two reasons:

1) Most people want to write simple single-threaded programs that do synchronous I/O. That means they only issue one request at a time. If their app is I/O bound, then there will always be some latency between the end of one request and the beginning of the next. The disk will be 100% idle during that latency (barring other access). Read-ahead means the disk is busy instead.

2) When *other* applications have the CPU, the disk could go idle too. Readahead could be still issuing requests on behalf of the app during that time.

In theory, a sophisticated (async reads) app might help replicate #1, and a big enough I/O request buffer might help #2. But let's face it, sync code is much easier to write and debug.

Improving readahead

Posted Feb 7, 2010 3:36 UTC (Sun) by giraffedata (guest, #1954) [Link]

Note that this effect isn't present if the application doesn't have any processing to do.
Nope. Two reasons:
...there will always be some latency between the end of one request and the beginning of the next

OK, I did oversimplify when I referred to an application with no processing to do, as that's impossible. To be more precise, I could say to the extent that an application has no processing to do, this overlap effect of readahead doesn't produce any application speedup. There will always be some speedup.

When *other* applications have the CPU, the disk could go idle too. Readahead could be still issuing requests on behalf of the app during that time

I guess you're talking about time the application is waiting for the CPU, which the readahead overlaps as well. Yes, I missed that. But in an I/O-bound application, this should be negligible, shouldn't it? With decent CPU allocation/scheduling, the process ought to get scheduled really soon after its read completes and keep the CPU until it starts the next one.