Messages in this thread | | | From | cd_smith@ou ... | Date | Mon, 12 Jul 1999 15:22:18 -0500 (CDT) | Subject | Re: [RFC] - Some notions that I would like comments on |
| |
Hi,
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/
| |