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

["David S. Miller" <davem@redhat.com>]

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
-
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/