lkml.org 
[lkml]   [2003]   [Mar]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch] "HT scheduler", sched-2.5.63-B3

On Thu, 6 Mar 2003, Linus Torvalds wrote:

> this is the part we're "throwing away", because the sleeper had already
> accumulated enough interactivity points.
>
> " + current->sleep_avg"
>
> this is the part that the waker _already_had_.
>
> if (ticks > MAX_SLEEP_AVG)
> ticks = MAX_SLEEP_AVG;
>
> This just says that the waker, too, will be limited by the "maximum
> interactivity" thing.

ok. I misread this part. It's actually a 'super boost' for interactive
tasks and tasks related to them.

> if (!in_interrupt())
> current->sleep_avg = ticks;

this (making a difference in characteristics based on in_interrupt()) was
something i tried before, but got killed due to generic wackyness :-)
Also, it's not really justified to isolate a process just because it got
woken up by a hw event.

> and this part says "we only give the potential boost to a _synchronous_
> waker" (ie a network packet that comes in and wakes somebody up in
> bottom half processing will _not_ cause an interactivity boost to a
> random process).

how about a keyboard interrupt?

> See? The patch maintains the rule that "interactivity" only gets created
> by sleeping. The only thing it really does is to change how we
> _distribute_ the interactivity we get. It gives some of the
> interactivity to the waker.

yes - i misunderstood this property of it - and this removed most of my
objections.

> Also, note how your "waiting for gcc to finish" is still not true. Sure,
> that "make" will be considered interactive, but it's not going to help
> the waker (gcc) any, since it will be interactive waiting for gcc to
> _die_.

there's also another phenomenon in the 'make -j5 hell': gas getting
boosted due to it waiting on the gcc pipeline. Now gcc will be 'back
boosted'. But we might be lucky and get away with it - testing will show.

> - "cc1" (slow) writes to a pipe to "as" (fast)
>
> "as" is fast, so as ends up waiting most of the time. Thus it ends up
> being marked interactive.
>
> When cc1 wakes up as, assuming as has been marked "maximally
> interactive", cc1 will get an interactivity boost too.
>
> Is this "wrong"? Maybe, if you see it from a pure "interactivity"
> standpoint. But another way of seeing it is to say that it automatically
> tries to _balance_ this kind of pipeline - since "cc1" is much slower
> and actually _wants_ the interactivity that "as" is clearly not ever
> going to actually get any real advantage from, it is actually likely to
> be perfectly fine give "cc1" a priority.

okay.

> In short, it's all about balancing. There are things that are
> "pro-interactive" (real sleeping), and there are things that are
> "anti-interactive" (using up your timeslice). The question is how you
> spread out the bonus points (or the negative points).

yes.

> The current scheduler doesn't spread them out at all. I think that's a
> bug, since pipelines of multiple processes are actually perfectly
> common, and X is only one example of this.

i have tried multiple schemes before to spread out interactivity, none
worked so far - but i have not tried any 'back-boosting' towards a CPU-hog
before, so it's an interesting experiment. If you look at the
child-timeslice thing that is a common vector for interactivity to spread.

> And my patch may spread it out _too_ much. Maybe we shouldn't give _all_
> of the left-over interactivity to the waker. Maybe we should give just
> half of it away..

yes, not spreading out could also make it possible to give it back via
multiple wakeup links, interactivity will 'diffuse' along wakeups.

Ingo

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

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