From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andi Kleen Subject: Re: [PATCH v6 3/5] qrwlock: Enable fair queue read/write lock Date: Mon, 18 Nov 2013 19:46:44 +0100 Message-ID: <20131118184644.GC29695@two.firstfloor.org> References: <1384267735-43213-1-git-send-email-Waiman.Long@hp.com> <1384267735-43213-5-git-send-email-Waiman.Long@hp.com> <20131118183433.GB29695@two.firstfloor.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Linus Torvalds Cc: Andi Kleen , Waiman Long , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , Arnd Bergmann , "linux-arch@vger.kernel.org" , the arch/x86 maintainers , Linux Kernel Mailing List , Peter Zijlstra , Steven Rostedt , Andrew Morton , Michel Lespinasse , Rik van Riel , "Paul E. McKenney" , Raghavendra K T , George Spelvin , Tim Chen , Aswin Chandramouleeswaran , Scott J Norton List-Id: linux-arch.vger.kernel.org > Why would it make sense here? There may be cases were switching all read locks to unfair may make concerete workloads slower. The effect is very visible in (non kernel) lock micro benchmarks, especially with HyperThreading. With very high contention or long enough critical sections the ordered lock usually wins, but it loses with lower contention. Unfortunately the "small critical section" case (even though it's really bad for any contended lock) is reasonably common :-/ [IMHO all of these should be fixed or "batched" somehow, but in some cases it is quite hard] However ordered locks definitely have more consistent performance. If prioritizing consistency over potential slow down in some cases is fine only having the ordered option is ok. -Andi From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from one.firstfloor.org ([193.170.194.197]:52170 "EHLO one.firstfloor.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752433Ab3KRSqq (ORCPT ); Mon, 18 Nov 2013 13:46:46 -0500 Date: Mon, 18 Nov 2013 19:46:44 +0100 From: Andi Kleen Subject: Re: [PATCH v6 3/5] qrwlock: Enable fair queue read/write lock Message-ID: <20131118184644.GC29695@two.firstfloor.org> References: <1384267735-43213-1-git-send-email-Waiman.Long@hp.com> <1384267735-43213-5-git-send-email-Waiman.Long@hp.com> <20131118183433.GB29695@two.firstfloor.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-arch-owner@vger.kernel.org List-ID: To: Linus Torvalds Cc: Andi Kleen , Waiman Long , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , Arnd Bergmann , "linux-arch@vger.kernel.org" , the arch/x86 maintainers , Linux Kernel Mailing List , Peter Zijlstra , Steven Rostedt , Andrew Morton , Michel Lespinasse , Rik van Riel , "Paul E. McKenney" , Raghavendra K T , George Spelvin , Tim Chen , Aswin Chandramouleeswaran , Scott J Norton Message-ID: <20131118184644.EZkVW63FeZVglrJSSOybprcU7k4K_f9GtRRUI2Im2Hs@z> > Why would it make sense here? There may be cases were switching all read locks to unfair may make concerete workloads slower. The effect is very visible in (non kernel) lock micro benchmarks, especially with HyperThreading. With very high contention or long enough critical sections the ordered lock usually wins, but it loses with lower contention. Unfortunately the "small critical section" case (even though it's really bad for any contended lock) is reasonably common :-/ [IMHO all of these should be fixed or "batched" somehow, but in some cases it is quite hard] However ordered locks definitely have more consistent performance. If prioritizing consistency over potential slow down in some cases is fine only having the ordered option is ok. -Andi