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/