Messages in this thread | | | Date | Thu, 02 Feb 2006 01:09:43 +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: > > >>>>So it is not a nice thing to tinker with unless there is good reason. >>> >>>unbound latencies with hardirqs off are obviously a good reason - but i >>>agree that the solution is not good enough, yet. >> >>Ah, so this is an RT tree thing where the scheduler lock turns off >>"hard irqs"? [...] > > > no, this is about the mainline kernel turning off hardirqs for a long > time. (i used the hardirqs-off terminology instead of irqs-off to > differentiate it from softirqs-off a'ka local_bh_disable(). It's a > side-effect of working on the lock validator i guess ;). >
OK.
> >>[...] As opposed to something like the rwsem lock that only turns off >>your "soft irqs" (sorry, I'm not with the terminlogy)? > > > rwsems/rwlocks are not an issue in -rt because they have different > semantics there - and thus readers cannot amass. I do think rwsems and > rwlocks have pretty nasty characteristics [non-latency ones] for the > mainline kernel's use too, but that's not being argued here ;) >
But all I'm saying is that while there are equivalent magnitudes of interrupts off regions in mainline, there is little point introducing a hack like this to "solve" one of them.
Sure, rework one of them nicely to solve the issue for that case, or hack _all_ of them (not for mainline but for your specific RT system). But hacking just one does not make any sense.
Just because this one path actually _triggered_ due to a silly benchmark doesn't make it any more valid. I think it shouldn't be too hard to cause similar or worse latencies with the mmap_sem rwsem using the same number of threads.
If anyone is running hackbench 20 on their sound mixer, then they deserve to have overruns.
-- 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/
| |