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

From: David S. Miller (davem@redhat.com)
Date: Thu Jan 11 2001 - 00:19:41 EST


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/



This archive was generated by hypermail 2b29 : Mon Jan 15 2001 - 21:00:30 EST