You turned my words in my mouth. This was just a misunderstanding.
> > But since the Linux kernel still has normal locks, we either go to
> > eliminate those altogether, or think about priority inheritence for them.
>
> So look at Andrea and Linus's disgusting but good semaphore down. The good
> (better be common) case is atomic decrement + failed branch (to
> take advantage of branch prediction).
> Now, if we add priority
> inversion, this case better also prepare for a later
> priority promotion. Right? And preparing for a priority promotion is not
> a simple atomic decrement. At the very least, you have
> to set a variable identifying yourself -- atomically. So your claim that
> the common case is unchanged seems dubious. Once we admit that the
> common case suffers we can discuss cost vs benefit. But before then,
> it's no point.
I think you have to promote when you fall asleep. I think the only thing
you have to take care in the common case is to keep track of which task
owns a semaphore - then you can build the inheritance graph then. This is
somewhat costly, but could be worth the price. Priority inheritance should
go through a mechanism that makes the inheriting process forget the new
priority after the next rescheduling, and the schedule() call of priority
inheritance should make sure that the next one happens at least when
crossing the kernel border.
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/