From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753188AbbIHGhi (ORCPT ); Tue, 8 Sep 2015 02:37:38 -0400 Received: from mx2.suse.de ([195.135.220.15]:36965 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751455AbbIHGhe (ORCPT ); Tue, 8 Sep 2015 02:37:34 -0400 Date: Mon, 7 Sep 2015 23:37:25 -0700 From: Davidlohr Bueso To: Linus Torvalds Cc: Peter Zijlstra , Dave Chinner , Linux Kernel Mailing List , Waiman Long , Ingo Molnar Subject: Re: [4.2, Regression] Queued spinlocks cause major XFS performance regression Message-ID: <20150908063725.GA2164@linux-q0g1.site> References: <20150904054820.GY3902@dastard> <20150904071143.GZ3902@dastard> <20150904082954.GB3902@dastard> <20150904151427.GG18489@twins.programming.kicks-ass.net> <20150904152523.GR18673@twins.programming.kicks-ass.net> <20150907000546.GA27993@linux-q0g1.site> <20150907065703.GX3644@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 07 Sep 2015, Linus Torvalds wrote: >On Sun, Sep 6, 2015 at 11:57 PM, Peter Zijlstra wrote: >> >> Just to continue the argument for arguments sake, the function is named >> 'virt' (not paravirt) and tests the HYPERVISOR CPUID bit. How is that >> not appropriately named? > >Well, I think right now one issue is that you can't avoid it, even >when you want pure "raw hardware" spinlocks. > >I really think it should at the very least be inside CONFIG_PARAVIRT. Yeah, I think we all agree here. >Because it *is* about helping the hypervisor, so really is about >paravirtualization. Yes, this is how I interpret it as well. CONFIG_PARAVIRT seems like a suitable place as while it is known to induce in overhead for baremetal and distros tend to enable it by default - mainly for mem pvops (ie: in page fault paths), and having this function doesn't add any complexity or add make things much different than they already are. While it is true that CONFIG_HYPERVISOR_GUEST is a pre-req for anything pv, technically I think it's not as good a fit as CONFIG_PARAVIRT because the former is really about describing the hypervisor, and that's not what we're doing here. Thanks, Davidlohr