From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759493AbbIDPOd (ORCPT ); Fri, 4 Sep 2015 11:14:33 -0400 Received: from casper.infradead.org ([85.118.1.10]:35846 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750766AbbIDPOb (ORCPT ); Fri, 4 Sep 2015 11:14:31 -0400 Date: Fri, 4 Sep 2015 17:14:27 +0200 From: Peter Zijlstra To: Linus Torvalds Cc: Dave Chinner , Linux Kernel Mailing List , Waiman Long , Ingo Molnar Subject: Re: [4.2, Regression] Queued spinlocks cause major XFS performance regression Message-ID: <20150904151427.GG18489@twins.programming.kicks-ass.net> References: <20150904054820.GY3902@dastard> <20150904071143.GZ3902@dastard> <20150904082954.GB3902@dastard> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2012-12-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Sep 04, 2015 at 08:05:16AM -0700, Linus Torvalds wrote: > So at the very *minimum*, that second issue should be fixed, and the > loop in virt_queued_spin_lock() should look something like > > do { > while (READ_ONCE(lock->val) != 0) > cpu_relax(); > } while (atomic_cmpxchg(&lock->val, 0, _Q_LOCKED_VAL) != 0); > > which at least has a chance in hell of behaving well on the bus and in > a HT environment. True. > But I suspect that it would be even better for Dave to just disable > the whole thing, and see how the queued locks actually work. Dave, can > you turn that virt_queued_spin_lock() into just "return false"? In > fact, I would almost _insist_ we do this when CONFIG_PARAVIRT_SPINLOCK > isn't set, isn't that what our old ticket-spinlocks did? They didn't > screw up and degrade to a test-and-set lock just because they saw a > hypervisor - that only happened when things were paravirt-aware. No? The reason we chose to revert to a test-and-set is because regular fair locks, like the ticket and the queue thing, have horrible behaviour under vcpu preemption. > Dave, if you have the energy, try it both ways. But the code as-is for > "I'm running in a hypervisor" looks just terminally broken. People who > didn't run in hypervisors just never saw the breakage. He did, it mostly restores performance, but was quite erratic. Lock holder preemption problems get much worse with strict queueing. So even though he's typically not overloaded, any vcpu preemption can ripple through and create noise.