* Nick Piggin <nickpiggin@xxxxxxxxxxxx> 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:
"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
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.
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.
[...] 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