On Thu, 2019-08-22 at 06:27 +0200, h...@lst.de wrote: > On Thu, Aug 22, 2019 at 04:01:24AM +0000, Atish Patra wrote: > > The downside of this is that for every !cmask case in true SMP > > (more > > common probably) it will execute 2 extra cpumask instructions. As > > tlbflush path is in performance critical path, I think we should > > favor > > more common case (SMP with more than 1 core). > > Actually, looking at both the current mainline code, and the code > from my > cleanups tree I don't think remote_sfence_vma / __sbi_tlb_flush_range > can ever be called with NULL cpumask, as we always have a valid mm. >
Yes. You are correct. As both cpumask functions here will crash if cpumask is null, we should probably leave a harmless comment to warn the consequeunce of cpumask being null. > So this is a bit of a moot point, and we can drop andling that case > entirely. With that we can also use a simple if / else for the local > cpu only vs remote case. Done. > Btw, what was the reason you didn't like > using cpumask_any_but like x86, which should be more efficient than > cpumask_test_cpu + hweigt? I had it in v2 patch but removed as it can potentially return garbage value if cpumask is empty. However, we are already checking empty cpumask before the local cpu check. I will replace cpumask_test_cpu + hweight with cpumask_any_but(). -- Regards, Atish
