[lkml]   [2011]   [Jan]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC][RT][PATCH 4/4] rtmutex: Ensure only the top waiter or higher priority task can take the lock
    On 01/04/2011 12:02 PM, Steven Rostedt wrote:
    > On Thu, 2010-12-23 at 17:47 -0500, Steven Rostedt wrote:
    >> plain text document attachment
    >> (0004-rtmutex-Ensure-only-the-top-waiter-or-higher-priorit.patch)
    >> From: Lai Jiangshan <>
    >> In current rtmutex, the pending owner may be boosted by the tasks
    >> in the rtmutex's waitlist when the pending owner is deboosted
    >> or a task in the waitlist is boosted. This boosting is unrelated,
    >> because the pending owner does not really take the rtmutex.
    >> It is not reasonable.
    > I'm still hitting some bugs with the port to -rt, but I also noticed
    > something that doesn't look too good.
    > There's several places in the kernel where a task may release and
    > acquire the same lock multiple times in a row.
    > The old way of removing the pending owner from the lists and waking it
    > up once, would have the high prio task wake it up once, and then it can
    > grab the locks multiple times without modifying the list, since the
    > pending owner is already awake and not in the pi list anymore.
    > The new way has the owner remove the woken task from its pi list and
    > wakes it up, but when it steals the lock again, it adds this owner back
    > to its pi list. When it releases the lock, it wakes it up again and
    > removes it from its pi list again. This happens over and over again.

    It is a expected behavior. With this behavior: we can assume that
    if a lock has waiter(s), the top waiter is always on the owner's pi list
    and the owner gets/(will get) boosted from it.

    This simplifies the code and the logic. But performance is more important,
    I will send 2 patches for it in this weekend.


     \ /
      Last update: 2011-01-05 08:13    [W:0.023 / U:2.268 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site