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

Reply via email to