From: gneuner2@comcast.net   
      
   On Fri, 3 Oct 2025 16:18:47 -0000 (UTC), kegs@provalid.com (Kent   
   Dickey) wrote:   
      
   >In article <1759506155-5857@newsgrouper.org>,   
   >MitchAlsup   wrote:   
   >>   
   >>Stefan Monnier  posted:   
   >>   
   >>> >> | - 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.   
   >>   
   >>SASOS seems like a bridge too far.   
   >>>   
   >>>   
   >>>         Stefan   
   >   
   >Fork is not a problem with virtual tagged caches or SAS.  Normal fork   
   >starts the child with a copy of the parent's address mapping, and uses   
   >"Copy on Write" (COW) to create unique pages as soon as either process   
   >does a write.   
      
   Copy-On-Write (or Copy-On-Access) doesn't solve the fork problem in   
   SAS - which is that copied /pointers/ remain referencing objects in   
   the original process.  Under the multi-space model of Unix/Linux,   
   after a fork the copied pointers should be referencing the copied   
   objects in the new process.   
      
   Lacking a way to identify and fixup pointer values, under SAS by   
   simply copying data (COW or COA) you end unintentionally /sharing/   
   data.   
      
      
   >For it's entire existance, PA-RISC HP-UX supported virtual indexed   
   >caches in a SAS, and implemented fork using Copy On Access.  As soon as   
   >the child process touched any page for read or write, it got a copy, so   
   >it can only access its own pages (not counting read-only instruction   
   >pages).  This works fine, and it's not a performance issue.  The love   
   >folks have for COW is overblown.  Real code either immediately exec()'s   
   >(maybe doing some close()'s and other housekeeping first) or starts   
   >writing lots of pages doing what it wants to do as a new process.  Note   
   >since the OS knows it needs to copy pages, it can pre-copy a bunch of   
   >pages, such as the stack, and some basic data pages, to avoid some   
   >initial faults for the exec() case at least.   
      
   fork-exec is not a problem. fork alone is.   
      
   How did HP-UX on PA-RISC handle fork?   
      
      
   >Kent   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)