From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759816AbbIDP6k (ORCPT ); Fri, 4 Sep 2015 11:58:40 -0400 Received: from mail-io0-f177.google.com ([209.85.223.177]:33726 "EHLO mail-io0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751033AbbIDP6j (ORCPT ); Fri, 4 Sep 2015 11:58:39 -0400 MIME-Version: 1.0 In-Reply-To: <20150904153035.GH18489@twins.programming.kicks-ass.net> References: <20150904054820.GY3902@dastard> <20150904071143.GZ3902@dastard> <20150904082954.GB3902@dastard> <20150904151427.GG18489@twins.programming.kicks-ass.net> <20150904153035.GH18489@twins.programming.kicks-ass.net> Date: Fri, 4 Sep 2015 08:58:38 -0700 X-Google-Sender-Auth: GSSzgowWCl8yZV3TPJFoFrkqrho Message-ID: Subject: Re: [4.2, Regression] Queued spinlocks cause major XFS performance regression From: Linus Torvalds To: Peter Zijlstra Cc: Dave Chinner , Linux Kernel Mailing List , Waiman Long , Ingo Molnar 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 Fri, Sep 4, 2015 at 8:30 AM, Peter Zijlstra wrote: >> And even ignoring the "implementation was crap" issue, some people may >> well want their kernels to be "bare hardware" kernels even under a >> hypervisor. It may be a slim hypervisor that gives you all the cpus, >> or it may just be a system that is just sufficiently overprovisioned, >> so you don't get vcpu preemption in practice. > > Fair enough; I had not considered the slim hypervisor case. > > Should I place the virt_spin_lock() thing under CONFIG_PARAVIRT (maybe > even _SPINLOCKS) such that only paravirt enabled kernels when ran on a > hypervisor that does not support paravirt patching (HyperV, VMware, > etc..) revert to the test-and-set? My gut feel would be to try to match out old paravirt setup, which similarly replaced the ticket locks with the test-and-set lock, and try to match the situation where that happened? Looking at 4.1, back then we very statically just based on CONFIG_PARAVIRT_SPINLOCKS switched between the ticket lock behavior and the test-and-set lock. I think we should aim for matching that for now. Which is not to say that we can't tune this if somebody comes up with a better model. For example, the "test hypervisor bit" thing might still be a good idea: even *if* you have CONFIG_PARAVIRT_SPINLOCKS, maybe we can do the queued locks if we don't seem to be running under a hypervisor? Our old model was entirely static, the new queued spinlock slowpath could clearly be a *bit* more dynamic. But as a first rough draft, I think "replace ticket locks with queued locks, leave test-and-set lock condition the way it was" is the way to go. Particularly since clearly the virtualized behavior had not gotten enough testing.. Linus