Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1220516

Re: [4.2, Regression] Queued spinlocks cause major XFS performance regression

From Davidlohr Bueso <dave@stgolabs.net>
Newsgroups linux.kernel
Subject Re: [4.2, Regression] Queued spinlocks cause major XFS performance regression
Date 2015-09-08 08:40 +0200
Message-ID <q6kJs-4IZ-15@gated-at.bofh.it> (permalink)
References (5 earlier) <q50Wu-5QK-11@gated-at.bofh.it> <q516c-61Z-29@gated-at.bofh.it> <q5Sat-5Rx-7@gated-at.bofh.it> <q5Yzg-6qO-1@gated-at.bofh.it> <q6bwt-863-15@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Mon, 07 Sep 2015, Linus Torvalds wrote:

>On Sun, Sep 6, 2015 at 11:57 PM, Peter Zijlstra <peterz@infradead.org> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Re: [4.2, Regression] Queued spinlocks cause major XFS performance regression Linus Torvalds <torvalds@linux-foundation.org> - 2015-09-07 22:50 +0200
  Re: [4.2, Regression] Queued spinlocks cause major XFS performance  regression Davidlohr Bueso <dave@stgolabs.net> - 2015-09-08 08:40 +0200
  Re: [4.2, Regression] Queued spinlocks cause major XFS performance  regression Peter Zijlstra <peterz@infradead.org> - 2015-09-08 12:10 +0200
    Re: [4.2, Regression] Queued spinlocks cause major XFS performance regression Linus Torvalds <torvalds@linux-foundation.org> - 2015-09-08 19:50 +0200

csiph-web