lkml.org 
[lkml]   [2011]   [Jan]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [RFC][RT][PATCH 3/4] rtmutex: Revert Optimize rt lock wakeup
    From
    Date
    On Mon, 2011-01-03 at 14:06 -0500, Steven Rostedt wrote:

    >
    > if (adaptive_wait(&waiter, orig_owner))
    > sleep = 1;
    > else
    > sleep = 0;
    >
    > if (sleep)


    > raw_spin_lock(&lock->wait_lock);
    > saved_state = rt_set_current_block_state(saved_state);
    > if (!lock->owner && &waiter == rt_mutex_top_waiter(lock))
    > sleep = 0;
    > raw_spin_unlock(&lock->wait_lock);

    I may be able to remove the above locks and replace it with:

    saved_state = rt_set_current_blocked_state(saved_state);
    if (orig_owner == rt_mutex_owner(lock))
    schedule_rt_mutex(lock);

    -- Steve


    > if (sleep)
    > schedule_rt_mutex(lock);
    > saved_state = rt_restore_current_blocked_state(saved_state);
    > }
    >
    > Otherwise we can risk the wakeup_next_waiter() missing the wakeup.
    >
    > To clarify, we want the adaptive_wait() to run as TASK_RUNNING. Then if
    > we must sleep, then we must set the state to TASK_UNINTERRUPTIBLE, test
    > again if we can still the lock, and if not then sleep. Otherwise, if a
    > wakeup happens just before we set the state to TASK_UNINTERRUPTIBLE,
    > then we miss the wake up all together.
    >
    > I can do this change, and see what impact it makes.
    >
    > I'm also curious if this ever worked? If it did not, then are you sure
    > your tests that show the benefit of it was true. I don't have a large
    > scale box at my disposal ATM, so I can only see what this does on 4way
    > machines.
    >
    > -- Steve
    >




    \
     
     \ /
      Last update: 2011-01-03 21:25    [W:0.022 / U:0.220 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site