From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966476AbbBCTnj (ORCPT ); Tue, 3 Feb 2015 14:43:39 -0500 Received: from mga09.intel.com ([134.134.136.24]:9339 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756091AbbBCTni (ORCPT ); Tue, 3 Feb 2015 14:43:38 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.09,514,1418112000"; d="scan'208";a="646829918" Message-ID: <1422992616.9530.78.camel@schen9-desk2.jf.intel.com> Subject: Re: [PATCH 4/5] locking/rwsem: Avoid deceiving lock spinners From: Tim Chen To: Jason Low Cc: Davidlohr Bueso , Peter Zijlstra , Ingo Molnar , "Paul E. McKenney" , Michel Lespinasse , linux-kernel@vger.kernel.org Date: Tue, 03 Feb 2015 11:43:36 -0800 In-Reply-To: <1422986041.2368.3.camel@j-VirtualBox> References: <1422609267-15102-1-git-send-email-dave@stgolabs.net> <1422609267-15102-5-git-send-email-dave@stgolabs.net> <1422669098.9530.33.camel@schen9-desk2.jf.intel.com> <1422671289.28351.1.camel@stgolabs.net> <1422983812.9530.43.camel@schen9-desk2.jf.intel.com> <1422986041.2368.3.camel@j-VirtualBox> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.8.5 (3.8.5-2.fc19) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2015-02-03 at 09:54 -0800, Jason Low wrote: > On Tue, 2015-02-03 at 09:16 -0800, Tim Chen wrote: > > > > > > > > > > + if (READ_ONCE(sem->owner)) > > > > > + return true; /* new owner, continue spinning */ > > > > > + > > > > > > > > Do you have some comparison data of whether it is more advantageous > > > > to continue spinning when owner changes? After the above change, > > > > rwsem will behave more like a spin lock for write lock and > > > > will keep spinning when the lock changes ownership. > > > > > > But recall we still abort when need_resched, so the spinning isn't > > > infinite. Never has been. > > > > > > > Now during heavy > > > > lock contention, if we don't continue spinning and sleep, we may use the > > > > clock cycles for actually running other threads. > > > > > > Under heavy contention, time spinning will force us to ultimately block > > > anyway. > > > > The question is under heavy contention, if we are going to block anyway, > > won't it be more advantageous not to continue spinning so we can use > > the cycles for useful task? > > Hi Tim, > > Now that we have the OSQ logic, under heavy contention, there will still > only be 1 thread that is spinning on owner at a time. That's true. We cannot have the lock grabbed by a new write contender as any new writer contender of the lock will be queued by the OSQ logic. Only the thread doing the optimistic spin is attempting write lock. In other word, switching of write owner of the rwsem to a new owner cannot happen. Either write owner stay as the original one, or we don't have a write owner. So using test of write owner switching as an indicator of congestion is incorrect. If my reasoning above is sound, then the check + if (READ_ONCE(sem->owner)) + return true; /* new owner, continue spinning */ + is unnecessary and can be removed, as we cannot have a new write owner of the rwsem, other than the thread doing optimistic spinning. Tim