[Haifux] SSD and linux

[Doron Zuckerman]

Hi Muli,

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.

> Try to find the place where the faulting process is put to sleep
and convert that code to busy wait instead, terminating the busy-wait
when the page has been brought in.

That's exactly what we are looking for, so far with no success...
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.
Do you have any idea where we can find this?

Thanks,

Ronen & Doron

On Thu, Sep 18, 2008 at 4:49 PM, Muli Ben-Yehuda <muli at il.ibm.com> wrote:

> On Thu, Sep 18, 2008 at 12:27:36PM +0300, Doron Zuckerman wrote:
>
> > I'm not sure it will speed up the OS, however I'm doing an academic
> > research on the matter as part of a project I'm taking, and I plan
> > to check this point.
>
> I'm pretty sure it won't.
>

>
> > The leading thought was that since the SSD is not a mechanical
> > drive, pages can be brought faster in this way, and there is no need
> > to context switch, thus, avoiding the overhead included.
>
> I suggest a much simpler exercise:
>
> (a) time how long it takes to read a block of data from the SSD
> (b) time how long a context switch takes
>
> See that (b) is orders of magnitude faster than (a).
>
> > So far I found the function "__generic_make_request" in file
> > "ll_blk".  This function calls a sub function named "might_sleep".
> > I have deleted the call to this function whenever I'm in a
> > pagefault, however I'm not sure if this function casuses the sleep,
> > or is just used for debugging in order to check if we entered a
> > suspend state.
>
> might_sleep() is a debugging aid, which is used by code that might
> sleep in order to check that it hasn't been called in a context where
> you can't sleep (non-process context such as an interrupt handler).
>
> > My question is if this is the function I should change in order to
> > accept the change I'm willing to get, or if the change should be
> > made in > q->make_request_fn which, according to my understanding,
> > belongs to the specific driver I'm using.
>
> Neither. Take a look at the page fault path for a major fault. What it
> does (from 10,000 feet) is initiate reading the page from disk, and
> then going t sleep until the page is ready. Going to sleep in the page
> fault path is what causes the context switch you want to avoid. What
> you want to do instead of going to sleep is busy-wait for the
> data. Try to find the place where the faulting process is put to sleep
> and convert that code to busy wait instead, terminating the busy-wait
> when the page has been brought in.
>
> Cheers,
> Muli
> --
> Workshop on I/O Virtualization (WIOV '08)
> Co-located with OSDI '08, Dec 2008, San Diego, CA
> http://www.usenix.org/wiov08
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://haifux.org/pipermail/haifux/attachments/20080918/d0e02956/attachment.html