Messages in this thread | | | Date | Sun, 1 Aug 1999 22:22:35 +0200 (MEST) | From | Bernd Paysan <> | Subject | Re: priority inversion |
| |
On Sat, 31 Jul 1999 yodaiken@chelm.cs.nmt.edu wrote: > I thought you had advocated getting rid of spin_locks altogether.
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/
| |