Ingo Molnar wrote:
* Nick Piggin <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
