[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1400707009.4661.23.camel@j-VirtualBox>
Date: Wed, 21 May 2014 14:16:49 -0700
From: Jason Low <jason.low2@...com>
To: Davidlohr Bueso <davidlohr@...com>
Cc: mingo@...nel.org, peterz@...radead.org, tglx@...utronix.de,
akpm@...ux-foundation.org, tim.c.chen@...ux.intel.com,
paulmck@...ux.vnet.ibm.com, hpa@...or.com, waiman.long@...com,
aswin@...com, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH] mutex: Documentation rewrite
On Wed, 2014-05-21 at 10:41 -0700, Davidlohr Bueso wrote:
> From: Davidlohr Bueso <davidlohr@...com>
> + The MCS lock (proposed by Mellor-Crummey and Scott) is a simple spinlock
> + with the desirable properties of being fair and with each cpu trying
> + to acquire the lock spinning on a local variable. It avoids expensive
> + cacheline bouncing that common test-and-set spinlock implementations
> + incur. An MCS-like lock is specially tailored for optimistic spinning
> + for sleeping lock implementation.
Would it be helpful to also briefly mention the benefit of using the
specially tailored MCS lock? Maybe something along the lines of: an
important feature of the customized MCS lock is that it has the extra
property that spinners are able to exit the MCS spinlock queue when they
needs to reschedule. This further helps avoid situations where MCS
spinners that need to reschedule would continue waiting to spin on mutex
owner, only to go directly to slowpath upon obtaining the MCS lock.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists