* Nick Piggin <[email protected]> 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 ;).
> [...] 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 ;)
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
