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
