Opinion: Personally, I think the approach in Andrew's patch
is the way to go.
Not because it can give the absolute best results.
But rather, it is because it says "here is where a lot
of time is spent".
This has two huge benefits:
1) It tells us where possible algorithmic improvements may
be possible. In some cases we may be able to improve the
code to the point where the pre-emption points are no
longer necessary and can thus be removed.
2) It affects only code which can burn a lot of cpu without
scheduling. Compare this to schemes which make the kernel
fully pre-emptable, causing _EVERYONE_ to pay the price of
low-latency. If we were to later fine algorithmic
improvements to the high-latency pieces of code, we
couldn't then just "undo" support for pre-emption because
dependencies will have swept across the whole kernel
already.
Pre-emption, by itself, also doesn't help in situations
where lots of time is spent while holding spinlocks.
There are several other operating systems which support
pre-emption where you will find hard coded calls to the
scheduler in time-consuming code. Heh, it's almost like,
"what's the frigging point of pre-emption then if you
still have to manually check in some spots?"
Bug: In the tcp_minisock.c changes, if you bail out of the loop
early (ie. max_killed=1) you do not decrement tcp_tw_count
by killed, which corrupts the state of the TIME_WAIT socket
reaper. The fix is simple, just duplicate the tcp_tw_count
decrement into the "if (max_killed)" code block.
Later,
David S. Miller
davem@redhat.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/