With the caveat that I didn't write the original message (so I may be the
one without a clue here) I think a few people are missing the point on
this speculative I/O thing. I don't know that it's a good idea, but it's
at least worth understanding and evaluating. As I see it, the big
difference between "speculative" I/O and asynchronous I/O is the
interface. Speculative I/O would appear to be a blocking I/O call, but as
soon as it queued the I/O request, it would return. The result page would
be marked as unreadable and unwriteable, and the actual I/O blocking would
be done on a page fault.
This simplifies the interface a lot and allows a lot of current programs
to benefit from non-blocking I/O -- maybe. There are a few things to
think about, like:
1. What about error handling. If a drive crashes and burns during a
blocking read, you get an error... if it does so during a speculative
read, you can't find out until the page fault. This breaks the interface
in a pretty substantial way and I don't see a way around it.
2. Most applications will look at data as soon as it's read from the disk
-- so you probably won't get much of a performance advantage unless
programs are written to take advantage of this, in much the same way as
instruction level concurrency of CPU's, but I don't think compilers can
help much this time. :(
3. What's the cost like on a page fault? I'm not familiar with these
sorts of things. More importantly, how much will we increase the cost of
a page fault by adding another case (that being that the page is linked to
a pending speculative I/O) to the page fault code, and what will the cache
impact be?
4. What's the effect on code complexity? If this provides negligible
performance gains and makes the code a lot harder to understand, then I'm
against it.
Chris Smith <cd_smith@ou.edu>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/