On Thu, 2018-10-25 at 11:29 -0600, Tamas K Lengyel wrote: > On Thu, Oct 25, 2018 at 11:23 AM Dario Faggioli > 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 -- <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Software Engineer @ SUSE https://www.suse.com/