Messages in this thread | | | Date | Thu, 02 Feb 2006 01:54:52 +1100 | From | Nick Piggin <> | Subject | Re: [PATCH] Avoid moving tasks when a schedule can be made. |
| |
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/
| |