sr (nobody.delete@this.nowhere.com) on September 20, 2021 6:02 am wrote:
> Paul A. Clayton (paaronclayton.delete@this.gmail.com) on September 18, 2021 2:35 pm wrote:
> (and if one does not have aliases in a virtually tagged cache
> > one can defer translation until time to access a memory-side cache or later with the obvious benefit
> > of permissions being smaller (and potentially coarser-grained) than translations).
>
> That's only possible with single-threading systems or systems without memory coherence. There is
> aliases in same virtual address space if there's many cores running same process with ability to
> share memory concurrently in different caches.

There *could be* aliases, but it's not strictly necessary.
"Single address space" is also a sane policy, at least as long as virtual address space is many times bigger than physical memory.
There are performance implications, like you can't share code segments between processes unless they are position-independent and fork() not followed by exec() is going to be slow, but I would think that in majority of real-world scenarios the observed performance cost is single-digit per cents or less.
There are advantages too. For example, you can freely exchange pointers to shared memory without the fear of different mappings in different processes.
mmap(,MAP_FIXED) would fail in most situations, but I think that it was never guaranteed to work by POSIX standards.


https://en.wikipedia.org/wiki/Single_address_space_operating_system


If you want to tell me that it is a pipe dream and that people are not going to change way they were doing general-purpose kernels for sake of relatively small HW simplification, then you don't have to.
I agree that developing general-purpose CPU that only supports SASOS *today* is commercially insane.

> Those aliases need also solved and serialize accesses
> to being able retain memory coherence. To do that for many virtual address spaces cpu's memory coherence
> system needs to translate all memory mappings to one address space - it can be some other than physical
> layer if for some reason has to be(protection against side-channels...)
>
>