Don't flush TLB entries, Share them!

This proposal has been rejected.

*

One Line Summary

Adding shared context/shared TLB support to the Linux kernel

Abstract

To help address the issue of which TLB entries to flush when address spaces are switched, some MMUs have introduced the concept of ‘tagged’ TLB entries. In such implementations, TLB entries contain a tag that is associated with a unique address space. When the MMU is searching for a virtual address translation, the tag as well as the virtual address must match for a hit. In this way, the TLB can contain multiple entries with the same virtual address but with unique tags. As a result, it is not always necessary to flush TLB entries when switching address spaces.

Beginning with SPARC Niagara 2 Processors, the MMU contains an additional ‘tag’. Actually these tags are called context identifiers on SPARC and are stored in two context ID registers: 0 and 1. When searching the TLB, the MMU will find a match if the virtual address matches and the ID contained in context register 0 or context register 1 matches.

In the Linux kernel today, only context register 0 is set and used by the MMU. Solaris has made use of the additional context register for shared mappings. If two tasks share an appropriate mapping, then both tasks set context register 1 to the same value and associate that value with the shared mapping. In this way, both tasks can use the same TLB entries for the shared mapping.

This presentation will explore adding shared context/shared TLB support to the Linux kernel. At this time, SPARC is the only processor/MMU capable of this functionality. At the lowest levels, there will need to be ‘plumbing’ added to support programming of the MMU and management of associated structures such as the Translation Storage Buffer (TSB). This of course, will be specific to the SPARC architecture. However, there is the need for ‘plumbing’ in the architecture independent layers as well. User level code must somehow specify the desire for shared context/TLB mappings. And, this desire must be maintained in the mapping structures themselves before being passed down to the architecture specific code. The presentation will seek input about the best ways to plumb shared context support into the kernel.

Early prototype results will be available to demonstrate the potential benefit of this functionality.

Speaker

  • Biography

    Mike Kravetz works in Oracle’s mainline Linux kernel development group. His most recent focus has been in the area memory management.

Leave a private comment to organizers about this proposal