On Tue, Jun 13, 2017 at 11:09 PM, Juergen Gross <jgross@xxxxxxxx> wrote: > 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. > Right, fixed. > > 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>
