From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755387Ab3B0USQ (ORCPT ); Wed, 27 Feb 2013 15:18:16 -0500 Received: from mail-vc0-f171.google.com ([209.85.220.171]:54488 "EHLO mail-vc0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752945Ab3B0USP (ORCPT ); Wed, 27 Feb 2013 15:18:15 -0500 MIME-Version: 1.0 In-Reply-To: <512E6443.9050603@redhat.com> References: <20130206150403.006e5294@cuia.bos.redhat.com> <511BE4A3.8050607@redhat.com> <511C1204.9040608@redhat.com> <511C24A6.8020409@redhat.com> <512E376D.70105@redhat.com> <512E6443.9050603@redhat.com> Date: Wed, 27 Feb 2013 12:18:13 -0800 X-Google-Sender-Auth: As1Sj_hciKnBk8PiAkjJ03SDYy0 Message-ID: Subject: Re: [tip:core/locking] x86/smp: Move waiting on contended ticket lock out of line From: Linus Torvalds To: Rik van Riel Cc: Ingo Molnar , "H. Peter Anvin" , Linux Kernel Mailing List , Peter Zijlstra , aquini@redhat.com, Andrew Morton , Thomas Gleixner , Michel Lespinasse , linux-tip-commits@vger.kernel.org, Steven Rostedt , "Vinod, Chegu" , "Low, Jason" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 27, 2013 at 11:53 AM, Rik van Riel wrote: > > If we have two classes of spinlocks, I suspect we would be better > off making those high-demand spinlocks MCS or LCH locks, which have > the property that having N+1 CPUs contend on the lock will never > result in slower aggregate throughput than having N CPUs contend. I doubt that. The fancy "no slowdown" locks almost never work in practice. They scale well by performing really badly for the normal case, either needing separate allocations or having memory ordering problems requiring multiple locked cycles. A spinlock basically needs to have a fast-case that is a single locked instruction, and all the clever ones tend to fail that simple test. > I can certainly take profiles of various workloads, but there is > absolutely no guarantee that I will see the same bottlenecks that > eg. the people at HP have seen. The largest test system I currently > have access to has 40 cores, vs. the 80 cores in the (much more > interesting) HP results I pasted. > > Would you also be interested in performance numbers (and profiles) > of a kernel that has bottleneck spinlocks replaced with MCS locks? MCS locks don't even work, last time I saw. They need that extra lock holder allocation, which forces people to have different calling conventions, and is just a pain. Or am I confusing them with something else? They might work for the special cases like the sleeping locks, which have one or two places that take and release the lock, but not for the generic spinlock. Also, it might be worth trying current git - if it's a rwsem that is implicated, the new lock stealing might be a win. So before even trying anything fancy, just basic profiles would be good to see which lock it is. Many of the really bad slowdowns are actually about the timing details of the sleeping locks (do *not* enable lock debugging etc for profiling, you want the mutex spinning code to be active, for example). Linus