From: kegs@provalid.com   
      
   In article ,   
   Stefan Monnier   wrote:   
   >>> | - virtually tagged caches   
   >>> |   You can't really claim to be worst-of-the-worst without virtually   
   >>> |tagged caches.   
   >>> |  Tears of joy as you debug cache alias issues and of flushing caches   
   >>> |on context switches.   
   >> That is only true if one insists on OS with Multiple Address Spaces.   
   >> Virtually tagged caches are fine for Single Address Space (SAS) OS.   
   >   
   >AFAIK, the main problem with SASOS is "backward compatibility", most   
   >importantly with `fork`.  The Mill people proposed a possible solution,   
   >which seemed workable, but it's far from clear to me whether it would   
   >work well enough if you want to port, say, Debian to such   
   >an architecture.   
   >   
   >   
   >        Stefan   
      
   Copy-on-Access gives you 100% compatibility with all fork() semantics.   
      
   You can define SAS in a way that almost defeats virtual addresses, but   
   let's assume we have 48-bit virtual address space and 16-bit ASID, for   
   an effective 64-bit SAS.  We'll have every process using a different ASID.   
   And we'll assume the ASID affects dcache indexing so we have to handle that.   
      
   First process is ASID=1.  It forks, and the child is ASID=2.  It is a   
   completely new address space.  We'll assume they cannot see each other's   
   data in the dcache due to the virtual indexes being different.  So   
   ASID=1, VA=0x1000 maps to a different dcache index than ASID=2,   
   VA=0x1000 even if they map to the same physical address.  The ASID=2   
   process starts (for the sake of a simple explanation) with no pages   
   mapped, except it maps all the read-only instruction pages from ASID=1   
   as ASID=2.  (Note it doesn't matter if these are at different   
   instruction and/or data cache indexes since it's always read-only).  All   
   data pages from the ASID=1 process are made invalid (in the page table,   
   and removed from the TLB).  Now ASID=1 and ASID=2 are running   
   simultaneously.  If the ASID=1 process touches any data page, the OS   
   copies the contents of that original physical page to a new page, and   
   makes that new page available to the ASID=2 process.  This copy is the   
   real trick: in the dumbest possible implementation, the OS flushes the   
   data to DRAM, then copies it to the new physical address, and flushes   
   that to DRAM.  But systems with caches with virtual aliasing generally   
   provide ways to handle the aliasing in a more efficient way to do this   
   copying in the caches, at least in the L2 cache.  Once the copy of the   
   one page is done, the OS then makes the corresponding ASID=1 page   
   writeable, and continues.  Similarly, if the ASID=2 process touches a   
   page, it gets a copy of the ASID=1 page (which ASID=1 has not touched   
   yet), and then the OS gives the ASID=1 process write access to that   
   page.  Basically, both processes are "paging in" the ASID=1 pages.   
      
   ASID=1 keeps all of its physical pages.  ASID=2 get a copy of all the   
   physical pages from ASID=1 that it touches.   
      
   Note that COW has to go and make all pages of the initial process read-only,   
   which might be more work than to just make all pages invalid.   
      
   Kent   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)