lkml.org 
[lkml]   [2014]   [Jan]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [RFC 2/3] mutex: Modify the way optimistic spinners are queued
    From
    Date
    On Wed, 2014-01-15 at 10:10 -0500, Waiman Long wrote:
    > On 01/14/2014 07:33 PM, Jason Low wrote:
    > > * When there's no owner, we might have preempted between the
    > > @@ -503,8 +504,10 @@ __mutex_lock_common(struct mutex *lock, long state, unsigned int subclass,
    > > * we're an RT task that will live-lock because we won't let
    > > * the owner complete.
    > > */
    > > - if (!owner&& (need_resched() || rt_task(task)))
    > > + if (!owner&& (need_resched() || rt_task(task))) {
    > > + mspin_unlock(MLOCK(lock),&node);
    > > goto slowpath;
    > > + }
    > >
    > > /*
    > > * The cpu_relax() call is a compiler barrier which forces
    >
    > Maybe you can consider restructure the code as follows to reduce the
    > number of mspin_unlock() call sites:

    Yeah, I would prefer your method of using break and having the
    mspin_unlock() at the end of the loop, now that it would result in less
    # of mspin_unlock().

    Commit ec83f425dbca47e19c6737e8e7db0d0924a5de1b changed break to
    slowpath to make it more intuitive to read, but with this patch, there
    are benefits to using break.



    \
     
     \ /
      Last update: 2014-01-15 21:01    [W:3.988 / U:0.228 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site