From: kegs@provalid.com   
      
   In article ,   
   George Neuner   wrote:   
   >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   
      
   This is what I was saying: if you define SAS to only mean that each   
   process is living at a unique address, and it knows its full address,   
   then I don't wish to discuss that SAS.  That's like running without   
   virtual memory.   
      
   If you define SAS that all processes can see other running processes   
   addresses, and can directly read/write each others addresses (with protection   
   obviously), then that's the SAS HP PA-RISC ran in.   
      
   HP PA-RISC 64-bit creates a 64-bit global virtual address.  Each process   
   by convention lives in a smaller part of that, let's say a 48-bit space.   
   Each process has 8 32-bit Space Registers (not general registers, and   
   some are not writeable by the user, but 5 are writeable) which are OR'ed   
   in to bits [63:32] of the VA address bits formed by loads and stores to   
   form the GVA.  Of GVA bits [63:32], it's an OS convention how many bits   
   are effectively the ASID and how many are VA bits for the process.   
   The GVA is mostly transparent to the user process--they can read the Space   
   Registers and figure it out if they want to, but this was not usual.   
      
   [The architecture defines Space registers as up to 64-bit, so there's a 96-bit   
   GVA, but the hardware only implemented 32-bit Space registers with a 64-bit   
   GVA].   
      
   Note that at any time, user code can set Space Register 1 to 0, form   
   the address 0x12345678_12345670 in a register, and try to read and write   
   that address.  This will generally fail due to a Protection ID scheme, but   
   some Space Register values were reserved for shared libraries to share the   
   code at the same GVA in all processes.   
      
   So fork() is easy--no pointers in memory or registers are affected, the   
   OS assignes a new ASID, puts that in the upper bits of the Space   
   Registers for the new process, and it's off.  But all HP PA-RISC CPUs have   
   virtually indexed caches, where the ASID is mixed in with lower address   
   bits to "hash" the cache lookup.  So it needed to do COA since the new   
   ASID is different, so the same VA wouldn't see the cached data of the   
   old process.   
      
   Note that the OS sees all processes at once.  If it wants to read from   
   one process and write to another, it can just do Load, then Store.   
      
   Kent   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)