lkml.org 
[lkml]   [1998]   [Sep]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Interesting scheduling times
Linus Torvalds writes:
>
>
> On Fri, 18 Sep 1998, Rik van Riel wrote:
> > On Thu, 17 Sep 1998, Linus Torvalds wrote:
> > > Even under heavy load, the runqueue is seldom more than a few entries
> > > deep. More than 10 entries on the run-queue is already very rare, and
> >
> > This is a good point. Maybe the code should be semantically
> > QNX-like but with a different implementation? I'll think it
> > over...
>
> Note that you did the unfortunate "out-of-context" cut that I really want
> to clarify, so that people are really aware of it.
>
> It's really easy to generate a run-queue that is arbitrarily deep. So
> before people tell me to run 50 processes that just have a "for (;;)" loop
> in them, yes I know. And it's even "normal" behaviour under certain load,
> especially in physics etc where you have a lot of very CPU-intensive
> loads.
>
> So when I say "seldom more than a few entries deep", it's not really
> something I believe to be true all the time. The other part of the
> equation is the "scheduling time is significant" - if the scheduling time
> is not very significant then it doesn't matter how we handle the
> run-queue.
>
> So take my above assertion more on the lines of "it's almost unheard of to
> have a deep run-queue _and_ a significant scheduling overhead". Because if
> you have lots of runnable processes, scheduling itself is not hat the CPU
> tends to be doing: most CPU-time by far is spent actually running the
> processes themselves.
>
> So my claim is really that we should optimize for the _few_ processes case
> rather then for the many processes case. I know that's against what some
> people are used to, but I just think that it's true. And that's why I
> don't believe in multiple run-queues.

I'd agree with you if the heavily loaded system was just doing
bog-standard time sharing. My concern is that if you are also trying
to control an instrument at the same time, the schedule/wakeup times
of the RT processes doesn't suffer because of the long run queue.
Just putting the RT code on a different computer is not always the
best solution. Hence my suggestion for a separate RT run queue.

Note another advantage of a separate run queue is that apart for the
"expected" cost of scanning the run queue, you're also reducing the
memory footprint by scanning less entries. This is cache-friendly.

Regards,

Richard....

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

\
 
 \ /
  Last update: 2005-03-22 13:44    [W:0.089 / U:1.764 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site