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