From: ThatWouldBeTelling@thevillage.com   
      
   MitchAlsup wrote:   
   > EricP  posted:   
   >   
   >> EricP wrote:   
   >>> Robert Finch wrote:   
   >>>> ??? I think a hash table has this characteristic. Multiple VA pages   
   >>>> can point to a single physical page using a a hash table. Is it just a   
   >>>> performance issue? ASID is part of the hash/compare.   
   >>> Be careful about ASID's - they aren't just part of the virtual address   
   >>> in MMU's like x86. There is a logic aspect in the address compare.   
   >>> If the PTE Global flag is set then ASID is NOT included in the VA compare,   
   >>> if the PTE Global flag is clear then ASID is included in the VA compare.   
   >>>   
   >>> If the G flag is set on OS kernel pages then the effect is to make the   
   >>> kernel virtual pages one single address space on all cores with no   
   >>> associated ASID, while process virtual spaces reside in their own ASID's.   
   >>>   
   >>> The above is easy to implement in a CAM because the Global flag is   
   >>> part of the PTE entry. Compare the virtual page number (VPN) and if   
   >>> there is a PTE match, then if the PTE.G flag is set take ASID as matched,   
   >>> otherwise check if ASID is matched.   
   >>>   
   >>> But if you just tack the ASID onto the VA to get a larger VA and   
   >>> use that as an index then you don't get the same logic because   
   >>> the PTE.G flag that tells you whether ASID matters for that PTE,   
   >>> is on the PTE that you are looking up.   
   >> One could achieve the same effect as the CAM approach by picking off the   
   >> range of addresses assigned to the OS and assigning them to ASID = 0,   
   >> and having the process range use the curent non-zero ASID register.   
   >>   
   >> If we have a 64-bit VA with 4kB pages = 52-bit virtual page number   
   >> and we added a 12-bit ASID then that gives a 76-bit virtual space   
   >> with a 64-bit AS-VPN to look up. We reserve ASID=0 for the OS,   
   >> 1..4095 are for processes.   
   >   
   > SPARC V8 had 13-bit ASIDs and found that this was way to short for   
   > the market SUN was targeting. SPARC V9 went with 16-bit ASIDs and   
   > I think this is as SHORT as an ASID can be for "reasonable" future   
   > proofing.   
      
   It also depends on whether ASIDs are assigned globally for a whole system   
   or locally for each core. Local assignment for each core needs less bits.   
   For globally assigned ASID 16 bits sounds too small for today -   
   they recycle too often.   
      
   When ASIDs were first introduced on x86 I remember a certain amount   
   of concern for the effects they would have on the fully assoc TLB.   
   The 32-bit x86 has a 20-bit Virtual Page Number so adding a 12-bit ASID   
   would increase the TLB size and power usage by 60%.   
      
   Back then I spent some time looking at how to do local 4-bit ASIDs per-core.   
   That is, each core has its own 4-bit ASID counter and each process   
   remembers which ASID its used last on each core.   
   Each core's TLB retains entries for up to the last 16 processes to run   
   threads on that core, and each core recycles its ASID independently.   
   The 4-bit size was chosen based on the assumption that the odds are small   
   in a TLB containing useful entries beyond the last 16 processes to run.   
      
   This eliminates many the global ASID shoot downs but 4 bits is too small as   
   it would recycle too quickly causing too frequent local ASID invalidates.   
      
   Combining all the ideas, 16+ bit ASID, locally assigned per core,   
   with a batch TLB ASID invalidate mechanism using a bit mask for matching   
   ASIDs so I can invalidate all ids in just one of the groups I mentioned   
   elsewhere; GGxx_xxxx_xxxx_xxxx where GG is the 2-bit group number.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)