Find the answer to your Linux question:
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.
  1. #1
    Just Joined!
    Join Date
    Sep 2011
    Posts
    1

    Confusion regarding TLB flush


    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. 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?

    Thanks
    Arka

  2. #2
    Linux Guru Rubberman's Avatar
    Join Date
    Apr 2009
    Location
    I can be found either 40 miles west of Chicago, or in a galaxy far, far away.
    Posts
    11,158
    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 info
    Sometimes, real fast is almost as good as real time.
    Just remember, Semper Gumbi - always be flexible!

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •