[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1471985566.2916.18.camel@linux.intel.com>
Date: Tue, 23 Aug 2016 13:52:46 -0700
From: Tim Chen <tim.c.chen@...ux.intel.com>
To: Waiman Long <waiman.long@....com>,
Peter Zijlstra <peterz@...radead.org>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Jason Low <jason.low2@....com>,
Ding Tianhong <dingtianhong@...wei.com>,
Thomas Gleixner <tglx@...utronix.de>,
Will Deacon <Will.Deacon@....com>,
Ingo Molnar <mingo@...hat.com>,
Imre Deak <imre.deak@...el.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Davidlohr Bueso <dave@...olabs.net>,
Terry Rudd <terry.rudd@....com>,
"Paul E. McKenney" <paulmck@...ibm.com>,
Jason Low <jason.low2@...com>
Subject: Re: [RFC][PATCH 1/3] locking/mutex: Rework mutex::owner
On Tue, 2016-08-23 at 15:55 -0400, Waiman Long wrote:
> On 08/23/2016 08:46 AM, Peter Zijlstra wrote:
>
> I have 2 more comments about the code.
> 1) There are a couple of places where you only use 0x3 in mutex.c. They
> should be replaced by the symbolic name instead.
May be easier to read if (owner & 0x3) and
(owner & ~0x3) are changed to something like
_owner_flag(owner) and _owner_task(owner).
Tim
> 2) We should make __mutex_lock_slowpath() a noinline function just like
> __mutex_lock_killable_slowpath() or __mutex_lock_interruptible_slowpath().
>
> Cheers,
> Longman
Powered by blists - more mailing lists