Messages in this thread | | | Date | Sun, 1 Aug 1999 19:29:18 -0600 | From | yodaiken@chelm ... | Subject | Re: priority inversion |
| |
On Sun, Aug 01, 1999 at 10:22:35PM +0200, Bernd Paysan wrote: > 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.
Sorry. But spin_locks with sleep is possible and doesn't it defeat inheritance?
> > 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
Ok. Now we have a basis for discussion. What's the gain that makes "somewhat costly" addition to common case worth it?
> go through a mechanism that makes the inheriting process forget the new > priority after the next rescheduling, and the schedule() call of priority
So: P0: get sem A, inherit priority X; sleep on I/O; lose priority X while holding A ?is this correct?
- 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/
| |