[Haifux] SSD and linux
muli at il.ibm.com
Thu Sep 18 17:49:21 MSD 2008
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.
Workshop on I/O Virtualization (WIOV '08)
Co-located with OSDI '08, Dec 2008, San Diego, CA
More information about the Haifux