Re: [PATCH] Avoid moving tasks when a schedule can be made.

[Nick Piggin <nickpiggin@yahoo.com.au>]

Ingo Molnar wrote:
> * Nick Piggin <nickpiggin@yahoo.com.au> wrote:
>
>
> > Ingo Molnar wrote:

> > No, if you read what I'd been saying, I'm not dismissing the whole 
> > subject based on the workload. I'm saying that there is no point to 
> > include such a "fix" based on the numbers given by this workload (if 
> > there is a more meaningful one, then sure). Especially not while there 
> > are sources of equivalent latency.
>
>
> firstly, you are ignoring the fact that Steve never submitted this for 
> actual inclusion. His very first email stated:

You keep saying this. I'm talking about the general concept of
"avoid moving tasks when a schedule can be made", or some way to
reduce latencies in move_tasks. Obviously we are long past the fact
that this particular patch isn't the best implementation.

>   "I'm not convinced that this bail out is in the right location, but 
>    it worked where it is.  Comments are welcome."
>
> so i'm not sure why you are still pounding upon his patch and suggesting 
> that any solution to this problem is to be limited to the -rt kernel and 

Err, I'm not.

> > It is really simple: I can find a code path in the kernel, and work 
> > out how to exploit it by increasing resource loading until it goes 
> > bang (another example, tasklist_lock).
>
>
> we are busy fixing tasklist_lock latencies too. The point you are still 
> trying to make, that the scheduler should not be touched just because 
> there are other problem areas with unbound latencies, is still plain 
> illogical.

Actually my main argument is that it is not a realistic workload,
and that I'd prefer not to touch the fragile scheduler until I see
one. I think that's perfectly logical, but whatever.

> > But there are still places where interrupts can be held off for 
> > indefinite periods. I don't see why the scheduler lock is suddenly 
> > important [...]
>
>
> the scheduler lock is obviously important because it's the most central 
> lock in existence.

Now I call that argument much more illogical than any of mine. How
can such a fine grained, essentially per-cpu lock be "central", let
alone "most central"? And even if it were central, why would that
make it obviously important?

> > [...] I could have told you years ago what would happen if you trigger 
> > the load balancer with enough tasks.
>
>
> i very well know what move_tasks() can do. There used to be other ways 
> to provoke unbound latencies in the scheduler - e.g.  via pinned tasks, 
> for which we introduced the all_pinned hack. The all_pinned hack was 
> needed because the worst-case behavior was getting so bad on some larger 
> boxes under larger loads that it totally DoSed the system. So it's not 

But luckily the scheduler is basically completely non functional in
the presence of pinned tasks anyway, so this is the only time this
special case kicks in.

But sure, it is there. I don't see how that justifies more changes
in that place for no reason. As soon as I see a good reason then I'd
be more than happy to look into it myself.

--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com 
-
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/