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/