From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966367AbbBCRyJ (ORCPT ); Tue, 3 Feb 2015 12:54:09 -0500 Received: from g4t3427.houston.hp.com ([15.201.208.55]:58334 "EHLO g4t3427.houston.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751548AbbBCRyF (ORCPT ); Tue, 3 Feb 2015 12:54:05 -0500 Message-ID: <1422986041.2368.3.camel@j-VirtualBox> Subject: Re: [PATCH 4/5] locking/rwsem: Avoid deceiving lock spinners From: Jason Low To: Tim Chen Cc: Davidlohr Bueso , Peter Zijlstra , Ingo Molnar , "Paul E. McKenney" , Michel Lespinasse , linux-kernel@vger.kernel.org, jason.low2@hp.com Date: Tue, 03 Feb 2015 09:54:01 -0800 In-Reply-To: <1422983812.9530.43.camel@schen9-desk2.jf.intel.com> 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> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. So if another thread is able to obtain the lock before the spinner, we're only sending the top spinner of the lock to the slowpath. As long as the new lock owner is running, there is a chance for this top spinner to obtain the lock, and spinning would be useful. Since we have the need_resched() checks, this thread will block when there really is another task that should run over the spinning thread.