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

[Ingo Molnar <mingo@elte.hu>]

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

> Ingo Molnar wrote:
> >* Nick Piggin <nickpiggin@yahoo.com.au> wrote:
> >
> >
> >>What I am talking about is when you want a task to have the highest 
> >>possible scheduling priority and you'd like to guarantee that it is 
> >>not interrupted for more than Xus, including scheduling latency.
> >
> >
> >this is not a big issue in practice, because it's very hard to saturate 
> >current x86 systems running the -rt kernel with pure IRQ load. The APIC 
> >messages all have a natural latency, which serves as a throttler.
> >
> 
> Either way, you don't measure it. Doesn't matter. As I said, off 
> topic.

(sure we are measuring such effects too - our current worst-case latency 
paths are related to two-irqs-after-each-other scenarios.)

> >>
> >>Then it is a fine hack for the RT kernel (or at least an improved, 
> >>batched version of the patch). No arguments from me.
> >
> >
> >no, it is also fine for the mainline scheduler, as long as the patch is 
> >clean and does the obviously right thing [which the current patch doesnt 
> >offer]. A 1+ msec latency with irqs off is nothing to sniff at. Trying 
> 
> 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.

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

	Ingo