Re: Scheduling times revisited

Larry McVoy (lm@bitmover.com)
Mon, 28 Sep 1998 00:28:39 -0600


Victor Yodaiken:
> That is, you should be able to show that for Application X, wall
> clock time of T involves T_s time searching the queue where T_s is a
> substantial fraction of T.

Paul Barton-Davis <pbd@Op.Net>:
: Not quite. Thats true if you're interested in throughput. If you care
: about latency then the the test is something quite different: you only
: need show that T_s is comparable to or exceeds your desired latency.

I think you are correct but you missed his point. You're saying "if
the thread switch time is greater than the hard limit on the latency,
then you're screwed". Which is true. Victor is saying "If you have a
latency limit of T with some set of events {e1, e2, e3} which can occur
and delay your latency, then you need show that T_s is the longest event".

To restate: if you've got anything that can screw up your latency (and Mr
Gooch has insisted that this is a latency discussion, not a throughput
discussion), then you care first about eliminating the longest event
that can hurt you, then the next longest, and so on. What follows is
that if T_s is not the longest event, then we shouldn't be concerned
with it, we should be looking at something else.

I happen to agree with Victor's assessment, as do most basic performance
and RT texts, not to mention basic mathematics. It's my assessment that
this entire discussion is a 3rd or 4th order term and, while interesting,
is really pointless until the large problems are solved.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/