From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755812AbbCFTUw (ORCPT ); Fri, 6 Mar 2015 14:20:52 -0500 Received: from cantor2.suse.de ([195.135.220.15]:56718 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750933AbbCFTUv (ORCPT ); Fri, 6 Mar 2015 14:20:51 -0500 Message-ID: <1425669643.19505.46.camel@stgolabs.net> Subject: Re: sched: softlockups in multi_cpu_stop From: Davidlohr Bueso To: Linus Torvalds Cc: Jason Low , Ingo Molnar , Sasha Levin , Peter Zijlstra , LKML , Dave Jones Date: Fri, 06 Mar 2015 11:20:43 -0800 In-Reply-To: References: <54F41516.6060608@oracle.com> <54F98F1F.3080107@oracle.com> <20150306123233.GA9972@gmail.com> <1425662342.19505.41.camel@stgolabs.net> <1425668223.2475.94.camel@j-VirtualBox> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.12.9 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 Fri, 2015-03-06 at 11:05 -0800, Linus Torvalds wrote: > On Fri, Mar 6, 2015 at 10:57 AM, Jason Low wrote: > > > > Right, the can_spin_on_owner() was originally added to the mutex > > spinning code for optimization purposes, particularly so that we can > > avoid adding the spinner to the OSQ only to find that it doesn't need to > > spin. This function needing to return a correct value should really only > > affect performance, so yes, lockups due to this seems surprising. > > Well, softlockups aren't about "correct behavior". They are about > certain things not happening in a timely manner. > > Clearly the mutex code now tries to hold on to the CPU too aggressively. This patch was a performance "fix" for rwsems, where it works well mutexes. > > At some point people need to admit that busy-looping isn't always a > good idea. Especially if > > (a) we could idle the core instead > > (b) the tuning has been done based on som especial-purpose benchmark > that is likely not realistic > > (c) we get reports from people that it causes problems. > > In other words: Let's just undo that excessive busy-looping. The > performance numbers were dubious to begin with. Real scalability comes > from fixing the locking, not from trying to play games with the locks > themselves. Particularly games that then cause problems. I obviously agree with all those points, however fyi most of the testing on rwsems I do includes scaling address space ops stressing the mmap_sem, which is a real world concern. So while it does include microbenchmarks, it is not guided by them. Thanks, Davidlohr