Improving readahead [LWN.net]

Improving readahead

Posted Feb 7, 2010 2:19 UTC (Sun) by dmag (subscriber, #17775)
In reply to: Improving readahead by giraffedata
Parent article: Improving readahead

>> 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.

(Log in to post comments)

Improving readahead

Posted Feb 7, 2010 3:36 UTC (Sun) by giraffedata (subscriber, #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.