Re: Ongoing/future speculative mitigation work

From: Tamas K Lengyel <tamas.k.lengyel@gmail.com>
To: Dario Faggioli <dfaggioli@suse.com>
Cc: mpohlack@amazon.de, "Julien Grall" <julien.grall@arm.com>,
	"Jan Beulich" <JBeulich@suse.com>,
	joao.m.martins@oracle.com,
	"Stefano Stabellini" <sstabellini@kernel.org>,
	"Daniel Kiper" <daniel.kiper@oracle.com>,
	"Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>,
	aliguori@amazon.com, uwed@amazon.de,
	"Lars Kurth" <lars.kurth@citrix.com>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>,
	ross.philipson@oracle.com, "Matt Wilson" <msw@amazon.com>,
	"Boris Ostrovsky" <boris.ostrovsky@oracle.com>,
	JGross@suse.com, sergey.dyasli@citrix.com,
	"Wei Liu" <wei.liu2@citrix.com>,
	"George Dunlap" <george.dunlap@eu.citrix.com>,
	"Andrew Cooper" <andrew.cooper3@citrix.com>,
	Xen-devel <xen-devel@lists.xen.org>,
	mdontu <mdontu@bitdefender.com>,
	dwmw@amazon.co.uk, "Roger Pau Monné" <roger.pau@citrix.com>
Subject: Re: Ongoing/future speculative mitigation work
Date: Thu, 25 Oct 2018 10:25:28 -0600	[thread overview]
Message-ID: <CABfawhkcGspr8+0=A-vLq66HrFK1D7H_abTyMKd21h3Mk2gvNg@mail.gmail.com> (raw)
In-Reply-To: <9270f77c23dad0855a00030cc53ce4b2b9366d22.camel@suse.com>

On Thu, Oct 25, 2018 at 10:01 AM Dario Faggioli <dfaggioli@suse.com> wrote:
>
> On Wed, 2018-10-24 at 09:24 -0600, Tamas K Lengyel wrote:
> > > A solution to this issue was proposed, whereby Xen synchronises
> > > siblings
> > > on vmexit/entry, so we are never executing code in two different
> > > privilege levels.  Getting this working would make it safe to
> > > continue
> > > using hyperthreading even in the presence of L1TF.  Obviously, its
> > > going
> > > to come in perf hit, but compared to disabling hyperthreading, all
> > > its
> > > got to do is beat a 60% perf hit to make it the preferable option
> > > for
> > > making your system L1TF-proof.
> >
> > Could you shed some light what tests were done where that 60%
> > performance hit was observed?
> >
> I don't have any data handy right now, but I have certainly seen
> hyperthreading being beneficial for performance in more than a few
> benchmarks and workloads. How much so, this indeed varies *a lot* both
> with the platform and with the workload itself.
>
> That being said, I agree it would be good to have as much data as
> possible. I'll try to do something about that.
>
> > We have performed intensive stress-tests
> > to confirm this but according to our findings turning off
> > hyper-threading is actually improving performance on all machines we
> > tested thus far.
> >
> Which is indeed very interesting. But, as we're discussing in the other
> thread, I would, in your case, do some more measurements, varying the
> configuration of the system, in order to be absolutely sure you are not
> hitting some bug or anomaly.

Sure, I would be happy to repeat tests that were done in the past to
see whether they are still holding. We have run this test with Xen
4.10, 4.11 and 4.12-unstable on laptops and desktops, using credit1
and credit2, and it is consistent that hyperthreading yields the worst
performance. It varies between platforms but it's around 10-40%
performance hit with hyperthread on. This test we do is a very CPU
intensive test where we heavily oversubscribe the system. But I don't
think it would be all that unusual to run into such a setup in the
real world from time-to-time.

Tamas

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel