Re: [linux-audio-dev] low-latency scheduling patch for 2.4.0

David S. Miller
2001-01-11T13:20:22Z

Just some commentary and a bug report on your patch Andrew:

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