linux-kernel - Re: [PATCH v3] mutex: Documentation rewrite

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5384B735.6050501@hp.com>
Date:	Tue, 27 May 2014 12:03:01 -0400
From:	Waiman Long <waiman.long@...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, jason.low2@...com,
	aswin@...com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3] mutex: Documentation rewrite

On 05/23/2014 11:16 AM, Davidlohr Bueso wrote:
> From: Davidlohr Bueso<davidlohr@...com>
>
>
> +
> +(ii) midpath: aka optimistic spinning, tries to spin for acquisition
> +     when there are no pending waiters and the lock owner is currently

That is not true. The spinning code doesn't check if there is any 
pending waiters. So some tasks can be spinning while the others are 
sleeping. The only checks are: 1) The lock owner is running; 2) there is 
no other higher-priority ready-to-run task (need_resched).

> +     running on a different CPU. The rationale is that if the lock owner
> +     is running, it is likely to release the lock soon. The mutex spinners
> +     are queued up using MCS lock so that only one spinner can compete for
> +     the mutex.
> +
> +     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. 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 need 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.
> +
> +
> +(iii) slowpath: last resort, if the lock is still unable to be acquired,
> +      the task is added to the wait-queue and sleeps until it can be taken.

It would be more clear to say "until woken up by the unlock path".

Other than that, the others look fine to me.

-Longman




--
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/