On Thu, Sep 18, 2008 at 06:49:58PM +0300, Doron Zuckerman wrote: > Do you have any idea where we can find this?
I haven't looked at those bits recently, but it sounds like Gabi is pointing you to the right path. In any case, to be honest, I think what you propose doesn't make sense, even as "research". Look at it this way. When does busy waiting makes sense? When the overhead of sleeping is offset by the useful work that gets done while you sleep (or when you can't sleep). So let's say that the overhead of a context switch is T_c. Switching to some other task and back will cost 2*T_c. Assuming that any work that the task you switch to does is useful, busy waiting makes sense only if you can resume executing the faulting task within 2*T_c time. So, unless you can read the frame from the SSD within 2*T_c time (which I highly doubt...) busy waiting does not make sense. Another point to consider is that if you are running on a UP machine and your kernel isn't preemptible, and the work to submit the I/O to disk happens in some other context than the one you run in, if you busy wait the I/O may never get submitted, and you'll busy wait forever! Cheers, Muli -- Workshop on I/O Virtualization (WIOV '08) Co-located with OSDI '08, Dec 2008, San Diego, CA http://www.usenix.org/wiov08 _______________________________________________ Haifux mailing list Haifux@haifux.org http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux
