On 14/06/17 06:56, Andy Lutomirski wrote: > x86's lazy TLB mode used to be fairly weak -- it would switch to > init_mm the first time it tried to flush a lazy TLB. This meant an > unnecessary CR3 write and, if the flush was remote, an unnecessary > IPI. > > Rewrite it entirely. When we enter lazy mode, we simply remove the > cpu from mm_cpumask. This means that we need a way to figure out > whether we've missed a flush when we switch back out of lazy mode. > I use the tlb_gen machinery to track whether a context is up to > date. > > Note to reviewers: this patch, my itself, looks a bit odd. I'm > using an array of length 1 containing (ctx_id, tlb_gen) rather than > just storing tlb_gen, and making it at array isn't necessary yet. > I'm doing this because the next few patches add PCID support, and, > with PCID, we need ctx_id, and the array will end up with a length > greater than 1. Making it an array now means that there will be > less churn and therefore less stress on your eyeballs. > > NB: This is dubious but, AFAICT, still correct on Xen and UV. > xen_exit_mmap() uses mm_cpumask() for nefarious purposes and this > patch changes the way that mm_cpumask() works. This should be okay, > since Xen *also* iterates all online CPUs to find all the CPUs it > needs to twiddle. There is a allocation failure path in xen_drop_mm_ref() which might be wrong with this patch. As this path should be taken only very unlikely I'd suggest to remove the test for mm_cpumask() bit zero in this path. Juergen -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
