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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Doron Zuckerman Sent: Thursday, September 18, 2008 6:50 PM To: Muli Ben-Yehuda; Ronen Gruengras; haifux@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 <[EMAIL PROTECTED]> 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
_______________________________________________ Haifux mailing list Haifux@haifux.org http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux
