Messages in this thread | | | Date | Tue, 08 Jan 2002 12:13:57 -0800 | From | Andrew Morton <> | Subject | Re: [2.4.17/18pre] VM and swap - it's really unusable |
| |
Marcelo Tosatti wrote: > > > Andrew Morten`s read-latency.patch is a clear winner for me, too. > > AFAIK Andrew's code simply adds schedule points around the kernel, right? > > If so, nope, I do not plan to integrate it.
I haven't sent it to you yet :) It improves the kernel. That's good, isn't it? (There are already forty or fifty open-coded rescheduling points in the kernel. That patch just adds the missing (and most important) ten).
BTW, with regard to the "preempt and low-lat improve disk throughput" argument. I have occasionally seen small throughput improvements, but I think these may be just request-merging flukes. Certainly they were very small.
The one area where it sometimes makes a huuuuuge throughput improvement is software RAID.
Much of the VM and dirty buffer writeout code assumes that submit_bh() starts I/O. Guess what? RAID's submit_bh() sometimes *doesn't* start I/O. Because the IO is started by a different thread.
With the Riel VM I had a test case in which software RAID completely and utterly collapsed because of this. The machine was spending huge amounts of time spinning in page_launder(), madly submitting I/O, but never yielding, so the I/O wasn't being started.
-aa VM has an open-coded yield in shrink_cahce() which prevents that particular collapse. But I had a report yesterday that the mini-ll patch triples throughput on a complex RAID stack in 2.4.17. Same reason.
Arguably, this is a RAID problem - raidN_make_request() should be yielding. But it's better to do this in one nice, single, reviewable place - submit_bh(). However that won't prevent wait_for_buffers() from starving the raid thread.
RAID is not alone. ksoftirqd, keventd and loop_thread() also need reasonably good response times.
But given the number of people who have been providing feedback on this patch, and on the disk-read-latency patch, none of this is going anywhere, and mine will be the only Linux machines which don't suck. (Takes ball, goes home).
- - 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/
| |