[LKP] Re: [x86/mm/tlb] 6035152d8e: will-it-scale.per_thread_ops -13.2% regression

> This new "early lazy check" behavior could theoretically work both ways. > If threads tended to be waking up from idle when TLB flushes were being > sent, this would tend to reduce the number of IPIs. But, since they > tend to be going to sleep it increases the number of IPIs. > > Anybody have a better theory? I think we should probably revert the commit. Let’s get back to the motivation behind this patch. Originally we had an indirect branch that on system which are vulnerable to Spectre v2 translates into a retpoline. So I would not paraphrase this patch purpose as “early lazy check” but instead “more efficient lazy check”. There is very little code that was executed between the call to on_each_cpu_cond_mask() and the actual check of tlb_is_not_lazy(). So what it seems to happen in this test-case - according to what you say - is that *slower* checks of is-lazy allows to send fewer IPIs since some cores go into idle-state. Was this test run with retpolines? If there is a difference in performance without retpoline - I am probably wrong.

/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Enhanced IBRS, IBPB: conditional, RSB filling