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/