Results 1 to 2 of 2
Hi All, I as trying to track down sources of TLB flushes (x86_64, kernel version 2.6.31). In the process I found something interesting that I could not really understand why. ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
- 09-03-2011 #1
- Join Date
- Sep 2011
Confusion regarding TLB flush
I as trying to track down sources of TLB flushes (x86_64, kernel version 2.6.31). In the process I found something interesting that I could not really understand why. The issue is as follows:
Many system calls that modify a range of virtual memory addresses (e.g., munmap, madvise etc) needs to do TLB flushes to make sure old mappings are not used from TLB.
In that process they end up calling tlb_flush_mmu(...) function in include/asm-generic/tlb.h. The function takes argument for the start and the end of the virtual address range that needs to be flushed. But what is confusing is that this function ignores the address range parameters (start and end) for which the flushing was intended. Internally it then calls tlb_flush which in turn gets converted to flush_tlb_mm for x86. Calling flush_tlb_mm flushes all user mapping for the process. My question is that when the requirement was only to flush a range of address (which can be done by calling flush_tlb_range ), why all the mapping for the process was invalidated? Is there any other reason/ performance implication of doing it?
- 09-03-2011 #2
- Join Date
- Apr 2009
- I can be found either 40 miles west of Chicago, or in a galaxy far, far away.
I'm not sure, but it sounds like the API for tlb_flush_mmu(...) was intended to only flush a specific address range, but it may have been implemented to flush everything because of any number of reasons, from simplifying the internals (assuming flushing all user memory does not have any significant / negative side effects) so that it could get into the kernel in a more timely manner (pending releases, etc), to discovered problems in doing the range-specific flush instead of a full cache flush. In any case, I would suggest that you contact the kernel development team (The Linux Kernel Archives). Their kernel discussion mailing list can be subscribed to, and subscription information can be found at VGER.KERNEL.ORG - Majordomo infoSometimes, real fast is almost as good as real time.
Just remember, Semper Gumbi - always be flexible!