On Thu, Jul 23, 2015 at 07:41:24AM -0700, Dave Hansen wrote: > We had a discussion about this a few weeks ago: > > https://lkml.org/lkml/2015/6/25/666 > > The argument is that the CPU is so good at refilling the TLB that it > rarely waits on it, so the "cost" can be very very low. That was about a new optimization adding more infrastructure to extend these kind of optimizations, but the infrastructure has a cost so I'm not sure this is relevant for this discussion, as there is not infrastructure or overhead here. If we were to do close to 33 invlpg it would be a gray area, but it's just one. I also refer to code that is already in the kernel: if (base_pages_to_flush > tlb_single_page_flush_ceiling) { You wrote the patch that uses the tlb_single_page_flush_ceiling, so if the above discussion would be relevant with regard to flush_tlb_page, are you implying that the above optimization in the kernel, should also be removed? When these flush_tlb_range optimizations were introduced, it was measured with benchmark that they helped IIRC. If it's not true anymore with latest CPU I don't know but there should be at least a subset of those CPUs where this helps. So I doubt it should be removed for all CPUs out there. Also if flush_tlb_page is slower on x86 (I doubt), then x86 should be implement it without invlpg but for the common code it would still make sense to use flush_tlb_page. > On older CPUs we had dedicated 2M TLB slots. Now, we have an STLB that > can hold 2M and 4k entries at the same time. That will surely change > the performance profile enough that whatever testing we did in the past > is fairly stale now. > > I didn't mean mixing 4k and 2M mappings for the same virtual address. Thanks for the clarification, got what you meant now. I still can't see why flush_tlb_page isn't an obviously valid optimization though. The tlb_single_page_flush_ceiling optimization has nothing to do with 2MB pages. But if that is still valid (or if it has ever been valid for older CPUs), why is flush_tlb_page not a valid optimization at least for those older CPUS? Why is it worth doing single invalidates on 4k pages and not on 2MB pages? It surely was helpful to do invlpg invalidated on 4k pages, up to 33 in a row, with x86 CPUs as you wrote the code quoted above to do that, and it is still in the current kernel. So why are 2MB pages different? I don't see a relation with this and the fact 2MB and 4KB TLB entries aren't separated anymore. If something the fact the TLB can use the same TLB entry for 2MB and 4KB pages, means doing invlpg on 2MB is even more helpful with newer CPUs as there can be more 2MB TLB entries to preserve than before. So I'm slightly confused now. Thanks, Andrea -- 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>