Messages in this thread | | | Subject | Re: [RFC] - Some notions that I would like comments on | Date | Mon, 12 Jul 1999 17:42:56 -0300 | From | Jeff Dike <> |
| |
> 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.
Right. Which is why I called it speculative rather than asynchronous. It is asynchronous I/O under a synchronous interface.
> 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.
Check my more expanded writeup (http://www.mv.com/ipusers/karaya/ossf/ossf.html ). The short answer is that a shadow process would be created to hang on to the process state at the time of the request. If the request ends up failing, then this shadow process is activated, the original one is killed, and the shadow continues from the return with the correct return value. This complicates things because the original must be prevented from letting any indication of its success outside its address space until the request has actually succeeded. There would definitely be costs and I don't know whether it would turn out to be worth (and I'm actually somewhat doubtful) but it might be worth looking at, and other people might have some clever ideas on minimizing those costs.
> 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
What I had in mind are things like compilers which go chugging sequentially through a file and do expensive stuff on it (like parsing). It ought to be pretty easy for the I/O to stay ahead of the parse, and maybe a useful amount of parsing can be done before the data all comes in.
> 3. What's the cost like on a page fault? I'm not familiar with these > sorts of things.
Me neither.
> 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.
Ditto here too.
Jeff
- 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/
| |