Messages in this thread | | | Date | Fri, 21 May 2004 09:50:28 +0200 | From | Jens Axboe <> | Subject | Re: Random file I/O regressions in 2.6 [patch+results] |
| |
On Fri, May 21 2004, Nick Piggin wrote: > Andrew Morton wrote: > > >Open questions are: > > > >a) Why is 2.6 write coalescing so superior to 2.4? > > > >b) Why is 2.6 issuing more read requests, for less data? > > > >c) Why is Alexey seeing dissimilar results? > > > > > Interesting. I am not too familiar with 2.4's IO scheduler, > but 2.6's have pretty comprehensive merging systems. Could > that be helping, Jens? Or is 2.4 pretty equivalent?
2.4 will give up merging faster than 2.6, elevator_linus will stop looking for a merge point if the sequence drops to zero. 2.6 will always merge. So that could explain the fewer writes.
> What about things like maximum request size for 2.4 vs 2.6 > for example? This is another thing that can have an impact, > especially for writes.
I think that's pretty similar. Andrew didn't say what device he was testing on, but 2.4 ide defaults to max 64k where 2.6 defaults to 128k.
> I'll take a guess at b, and say it could be as-iosched.c. > Another thing might be that 2.6 has smaller nr_requests than > 2.4, although you are unlikely to hid the read side limit > with only 16 threads if they are doing sync IO.
Andrew, you did numbers for deadline previously as well, but no rq statistics there? As for nr_requests that's true, would be worth a shot to bump available requests in 2.6.
-- Jens Axboe
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |