From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752315AbcHHRhx (ORCPT ); Mon, 8 Aug 2016 13:37:53 -0400 Received: from merlin.infradead.org ([205.233.59.134]:56714 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752123AbcHHRhw (ORCPT ); Mon, 8 Aug 2016 13:37:52 -0400 Date: Mon, 8 Aug 2016 19:37:16 +0200 From: Peter Zijlstra To: Waiman Long Cc: Ingo Molnar , linux-kernel@vger.kernel.org, Linus Torvalds , Ding Tianhong , Jason Low , Davidlohr Bueso , "Paul E. McKenney" , Thomas Gleixner , Will Deacon , Tim Chen , Imre Deak Subject: Re: [PATCH v4 3/3] locking/mutex: Ensure forward progress of waiter-spinner Message-ID: <20160808173716.GZ6862@twins.programming.kicks-ass.net> References: <1468874366-56955-1-git-send-email-Waiman.Long@hpe.com> <1468874366-56955-4-git-send-email-Waiman.Long@hpe.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1468874366-56955-4-git-send-email-Waiman.Long@hpe.com> User-Agent: Mutt/1.5.23.1 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jul 18, 2016 at 04:39:26PM -0400, Waiman Long wrote: > As both an optimistic spinner and a waiter-spinner (a woken task from > the wait queue spinning) can be spinning on the lock at the same time, > we cannot ensure forward progress for the waiter-spinner. Therefore, > it is possible for the waiter-spinner to be starved of getting the > lock, though not likely. Right; yet your previous two changelogs/comments implied otherwise. > This patch adds a flag to indicate that a waiter-spinner is > spinning and hence has priority over the acquisition of the lock. A > waiter-spinner sets this flag while spinning. An optimistic spinner > will check this flag and yield if set. This essentially makes the > waiter-spinner jump to the head of the optimistic spinning queue to > acquire the lock. > > There will be no increase in size for the mutex structure for 64-bit > architectures. For 32-bit architectures, there will be a size increase > of 4 bytes. Alternative might be to use the LSB of mutex::owner, but that's going to be somewhat icky too. I'm not sure the 32bit platforms are going to be excited about growing struct mutex...