From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934481AbcBDW6E (ORCPT ); Thu, 4 Feb 2016 17:58:04 -0500 Received: from g1t6225.austin.hp.com ([15.73.96.126]:51217 "EHLO g1t6225.austin.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934264AbcBDW45 (ORCPT ); Thu, 4 Feb 2016 17:56:57 -0500 Message-ID: <1454626163.2072.55.camel@j-VirtualBox> Subject: Re: [PATCH] locking/mutex: Avoid spinner vs waiter starvation From: Jason Low To: huang ying Cc: Peter Zijlstra , Ding Tianhong , Waiman Long , Ingo Molnar , "linux-kernel@vger.kernel.org" , Davidlohr Bueso , Linus Torvalds , "Paul E. McKenney" , Thomas Gleixner , Will Deacon , Tim Chen , Waiman Long , jason.low2@hpe.com, scott.norton@hpe.com Date: Thu, 04 Feb 2016 14:49:23 -0800 In-Reply-To: References: <56A1638A.7050202@hpe.com> <20160122085422.GO6357@twins.programming.kicks-ass.net> <1453458019.9727.8.camel@j-VirtualBox> <20160122105312.GQ6357@twins.programming.kicks-ass.net> <20160122105652.GE6375@twins.programming.kicks-ass.net> <20160122110653.GF6375@twins.programming.kicks-ass.net> <56A235DC.2060900@hpe.com> <56A48566.9040206@huawei.com> <20160129095347.GA6356@twins.programming.kicks-ass.net> <56AC0F74.2040808@huawei.com> <20160201100824.GO6357@twins.programming.kicks-ass.net> <1454549736.2072.15.camel@j-VirtualBox> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4-0ubuntu2 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, 2016-02-04 at 16:55 +0800, huang ying wrote: > Hi, Low, > > On Thu, Feb 4, 2016 at 9:35 AM, Jason Low wrote: > > I've done some testing with this patch with some of the AIM7 workloads > > and found that this reduced throughput by about 10%. The reduction in > > throughput is expected since spinning as a waiter is less efficient. > > > > Another observation I made is that the top waiter spinners would often > > times require needing to reschedule before being able to acquire the > > lock from spinning when there was high contention. A waiter can go into > > the cycle of spin -> reschedule -> spin -> reschedule. So although the > > chance of starvation is reduced, this patch doesn't fully address the > > issue of waiter starvation. > > Could you share your workload? I want to reproduce it in 0day/LKP+ environment. CC'ing Scott, who wrote the automation scripts. Jason