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:

> > If it were generated by some real workload that cares, then I would care.
>
>
> well, you might not care, but i do. It's up to you what you care about, 
> but right now the scheduler policy is that we do care about latencies.  
> Yes, it's obviously all subject to common sense, and if something 
> triggers in a rare and extreme workload then any change related to it 
> has a _much_ higher barrier of acceptance than a common codepath. But
> your blanket dismissal of this whole subject based on the rarity of the
> workload is just plain wrong.

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.

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).

This is not really a justification for trying to "fix" it.

Unless somewhere there was an agreement that 1.5ms interrupt latency
was a bug, full stop.

> > > to argue that 'you can get the same by using rwsems so why should we 
> > > bother' is pretty lame: rwsems are rare and arguably broken in 
> > > behavior, and i'd not say the same about the scheduler (just yet :-).
> >
> > I don't think it is lame at all. They're fairly important in use in 
> > mmap_sem that I know of. And I have seen workloads where the up_write 
> > path gets really expensive (arguably more relevant ones than 
> > hackbench).
>
>
> they are broken e.g. in that they are mass-waking all the readers with 
> interrupts disabled. At a minimum rwsems should be declared irq-unsafe 
> (like mutexes), as all the substantial uses are in process-context 
> codepaths anyway. I'll revisit rwsems once the current mutex work is 
> done.

That would be great. Actually I have some patches that move the actual
waking of the tasks out from underneath the lock too which gave some
scalability benefits (and I'd imagine far less interrupt-off time, so
let me know when you start work on rwsems).

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 - I could have told you years ago what would happen if you
trigger the load balancer with enough tasks.

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