Re: Priority Inversion/Inheritance in Linux Kernel

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Jul 4, 2008 at 6:48 PM, Rene Herman <rene.herman@xxxxxxxxxxxx> wrote:
> On 04-07-08 02:05, Peter Teoh wrote:
>
>> I see....eh...or I don't see......the original problem was that the
>> highest prio cannot acquire the lock, even though it has the highest prio.
>
> No. That is or was not the problem. This I believe is the fundamental
> misunderstanding left.
>
> Please note how I said "All fine and well up to this point" when the
> high-prioriy process went to sleep since the low-priority process was
> holding the lock.
>
> Such is the nature of the mutex/futex locking model. Holding a lock
> _overrides_ any scheduler priority, makes it irrelevant, and this is how
> things are supposed to work. If we just have the high-priority and the
> low-priority process, we have no priority inversion issues, no problem.
>
> It's mixing in that third medium priority process that's causing the
> problem. It itself does _not_ grab the lock, yet it still keeps the
> high-priority process from running since it keeps the low priority process
> from running to the point where it releases the lock. So we have here a
> situation where a process that isn't holding a lock the higher priority
> process is waiting for is still keeping the higher priority process from
> running -- effectively, the medium priority process has a higher priority
> then the high-priority process since it has a higher priority then the
> low-priority process.
>
> That's the problem called "priority inversion".
>
> I suppose once that's clear, the priority inheritance solution will also be:
> just assign the priority of the high-prio process to the low-prio process
> when the high prio-process blocks on the lock so that the medium-prio
> process won't keep the (originally) low-prio process from running (tweak
> solution to "assign the maximum of current prio of lock holder and prio of
> process about to be blocked to lock holder" in the general case of more than
> just 3 possible processes ofcourse).
>
> Rene.
>

Ah....very clear and well written explanation - thank you for the
effort put into the writing.

And for the phenomena of "unbounded priority inversion", I found this
very useful:

http://lkml.org/lkml/2006/5/10/52

Thank you to Rene and Roberto for the discussion.....

-- 
Regards,
Peter Teoh

--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ


[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux