[Haifux] SSD and linux

[gabik]

q->make_request_fn  seems to call a function __make_request()
[blk_init_queue_node initializes a pointer to this function]
__make_request calls get_request_wait() which in turn calls
prepare_to_wait_exclusive() and later io_schedule().
 
So the logic is exactly like in 2.6.11, but a bit more complex.
 
Gabi
 
 

  _____  

From: haifux-bounces at haifux.org [mailto:haifux-bounces at haifux.org] On Behalf
Of Doron Zuckerman
Sent: Thursday, September 18, 2008 6:50 PM
To: Muli Ben-Yehuda; Ronen Gruengras; haifux at haifux.org
Subject: Re: [Haifux] SSD and linux


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/ff97192c/attachment.html