From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751511AbbEFLSh (ORCPT ); Wed, 6 May 2015 07:18:37 -0400 Received: from cantor2.suse.de ([195.135.220.15]:50260 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750968AbbEFLSg (ORCPT ); Wed, 6 May 2015 07:18:36 -0400 Message-ID: <1430911095.1940.28.camel@stgolabs.net> Subject: Re: [PATCH v4 1/2] locking/rwsem: reduce spinlock contention in wakeup after up_read/up_write From: Davidlohr Bueso To: Waiman Long Cc: Peter Zijlstra , Ingo Molnar , linux-kernel@vger.kernel.org, Jason Low , Scott J Norton , Douglas Hatch Date: Wed, 06 May 2015 04:18:15 -0700 In-Reply-To: <1430428337-16802-2-git-send-email-Waiman.Long@hp.com> References: <1430428337-16802-1-git-send-email-Waiman.Long@hp.com> <1430428337-16802-2-git-send-email-Waiman.Long@hp.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.12.11 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 Thu, 2015-04-30 at 17:12 -0400, Waiman Long wrote: > In up_write()/up_read(), rwsem_wake() will be called whenever it > detects that some writers/readers are waiting. The rwsem_wake() > function will take the wait_lock and call __rwsem_do_wake() to do the > real wakeup. For a heavily contended rwsem, doing a spin_lock() on > wait_lock will cause further contention on the heavily contended rwsem > cacheline resulting in delay in the completion of the up_read/up_write > operations. > > This patch makes the wait_lock taking and the call to __rwsem_do_wake() > optional if at least one spinning writer is present. The spinning > writer will be able to take the rwsem and call rwsem_wake() later > when it calls up_write(). With the presence of a spinning writer, > rwsem_wake() will now try to acquire the lock using trylock. If that > fails, it will just quit. > > Signed-off-by: Waiman Long > Suggested-by: Peter Zijlstra (Intel) Reviewed-by: Davidlohr Bueso