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

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

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

PS. I'd like to see you argue how they're broken in behaviour, and how
you're going to replace mmap_sem -- this is not a rhetorical statement,
I'd really be interested to see ;)

-- 
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com