Re: [Xen-devel] Ongoing/future speculative mitigation work

[Dario Faggioli <dfaggioli@xxxxxxxx>]

On Thu, 2018-10-25 at 11:29 -0600, Tamas K Lengyel wrote:
> On Thu, Oct 25, 2018 at 11:23 AM Dario Faggioli <dfaggioli@xxxxxxxx>
> wrote:
> > 
> > Having _everyone_ wanting to do actual stuff on the CPUs is, IMO,
> > one
> > of the worst workloads for hyperthreading, and it is in fact a
> > workload
> > where I've always seen it having the least beneficial effect on
> > performance. I guess it's possible that, in your case, it's
> > actually
> > really doing more harm than good.
> > 
> > It's an interesting data point, but I wouldn't use a workload like
> > that
> > to measure the benefit, or the impact, of an SMT related change.
> 
> Thanks, and indeed this test is the worst-case scenario for
> hyperthreading, that's was our goal. While a typical work-load may
> not
> be similar, it is a possible one for the system we are concerned
> about. 
>
Sure, and that is fine. But at the same time, it is not much, if at
all, related with speculative execution, L1TF and coscheduling. It's
just that, with this workload, hyperthreading is bad, and not much more
to say.

> So if at any given time the benefit of hyperthreading ranges
> between say +30% and -30% and we can't predict the workload or
> optimize it, it is looking like a safe bet to just disable
> hyperthreading. Would you agree?
> 
That's, AFAICR, the OpenBSD's take, back at the time of when TLBLeed
came out. But, no, I don't really agree. Not entirely, at least.

The way I see it, is that there are special workloads where  SMT gives,
say, -30%, and those should just disable it, and be done.

For others, it's perfectly fine to keep it on, and we should, ideally,
find a solution to the security issues it introduces, without
nullifying the performance benefit it introduces.

And when it comes to judge how good, or bad, such solutions are, we
should consider both the best and the worst case scenarios, and I'd say
that the best case scenario is more important, as for the worst case,
one could just disable SMT, as said above.

Regards,
Dario
-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Software Engineer @ SUSE https://www.suse.com/

Attachment: signature.asc
Description: This is a digitally signed message part

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