<div dir="ltr">Hi Muli,<br><br>It seems like a good idea to check the time of a single block read against a single context switch, we'll try looking more into it.<br>
<br><span style="color: rgb(102, 51, 255);">> Try to find the place where the faulting process is put to sleep</span><br style="color: rgb(102, 51, 255);"><span style="color: rgb(102, 51, 255);">
and convert that code to busy wait instead, terminating the busy-wait</span><br style="color: rgb(102, 51, 255);"><span style="color: rgb(102, 51, 255);">
when the page has been brought in.</span><br><br>That's exactly what we are looking for, so far with no success...<br>We tried following the page-fault path and got all the way to the call to q->make_request_fn (in the "__generic_make_request" function in the block\ll_rw_blk.c file). Till there we couldn't find anything that can put the current process into waiting. Our guess is that it is done somewere inside this function.<br>
Do you have any idea where we can find this?<br><br>Thanks,<br><br>Ronen & Doron<br><br><div class="gmail_quote">On Thu, Sep 18, 2008 at 4:49 PM, Muli Ben-Yehuda <span dir="ltr"><<a href="mailto:muli@il.ibm.com">muli@il.ibm.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">On Thu, Sep 18, 2008 at 12:27:36PM +0300, Doron Zuckerman wrote:<br>
<br>
> I'm not sure it will speed up the OS, however I'm doing an academic<br>
> research on the matter as part of a project I'm taking, and I plan<br>
> to check this point.<br>
<br>
</div>I'm pretty sure it won't. <br></blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<div class="Ih2E3d"><br>
> The leading thought was that since the SSD is not a mechanical<br>
> drive, pages can be brought faster in this way, and there is no need<br>
> to context switch, thus, avoiding the overhead included.<br>
<br>
</div>I suggest a much simpler exercise:<br>
<br>
(a) time how long it takes to read a block of data from the SSD<br>
(b) time how long a context switch takes<br>
<br>
See that (b) is orders of magnitude faster than (a).<br>
<div class="Ih2E3d"><br>
> So far I found the function "__generic_make_request" in file<br>
> "ll_blk". This function calls a sub function named "might_sleep".<br>
> I have deleted the call to this function whenever I'm in a<br>
> pagefault, however I'm not sure if this function casuses the sleep,<br>
> or is just used for debugging in order to check if we entered a<br>
> suspend state.<br>
<br>
</div>might_sleep() is a debugging aid, which is used by code that might<br>
sleep in order to check that it hasn't been called in a context where<br>
you can't sleep (non-process context such as an interrupt handler).<br>
<div class="Ih2E3d"><br>
> My question is if this is the function I should change in order to<br>
> accept the change I'm willing to get, or if the change should be<br>
> made in > q->make_request_fn which, according to my understanding,<br>
> belongs to the specific driver I'm using.<br>
<br>
</div>Neither. Take a look at the page fault path for a major fault. What it<br>
does (from 10,000 feet) is initiate reading the page from disk, and<br>
then going t sleep until the page is ready. Going to sleep in the page<br>
fault path is what causes the context switch you want to avoid. What<br>
you want to do instead of going to sleep is busy-wait for the<br>
data. Try to find the place where the faulting process is put to sleep<br>
and convert that code to busy wait instead, terminating the busy-wait<br>
when the page has been brought in.<br>
<div><div></div><div class="Wj3C7c"><br>
Cheers,<br>
Muli<br>
--<br>
Workshop on I/O Virtualization (WIOV '08)<br>
Co-located with OSDI '08, Dec 2008, San Diego, CA<br>
<a href="http://www.usenix.org/wiov08" target="_blank">http://www.usenix.org/wiov08</a><br>
</div></div></blockquote></div><br></div>