(Mill team) Re non-paged TLB: The Mill has non-paged protection in the PLB and paged translation in the TLB. It is true that a 'conventional' could have non-

(Mill team) Re non-paged TLB: The Mill has non-paged protection in the PLB and paged translation in the TLB. It is true that a 'conventional' could have non-paged translation, but non-paged translation would be slow. Really slow. Shudder to imagine how it would work internally :) Re SAS: Conventional machines are Multi-address-space (MAS). In a MAS, addresses can alias each another. Not so on the Mill (at least, if you deliberately alias in the Mill TLB you'll have to know that reads and writes will merge as they go off-chip etc; tricky, but can be useful in select low-level scenarios). On the Mill, everything that is shared between processes is global. On a Unix port, everything that is local to a process is 'local'. So MAP_SHARED gets addresses without the local bit set and MAP_PRIVATE does. When we fork(), we have some choices. The OS picks a new local offset for the new process, meaning that local pointers don't alias one another. We could straight away clone the protection entries and page tables. Or, as an implementation detail, depending on the extent to which the PLB self-manages on the particular Mill member, just let the PLB trap. As the new forked process accesses memory ranges for the first time the PLB will miss and there will be the classic trap. In the trap, the handler can set up COW lazily and for the memory regions that are actually touched by the child. I am simplifying it a bit ;) Most fork() is just going to exec(), and the latter will win. Some people are still using fork() in other ways, and they may benefit from an aggressive COW up front on fork(). Swings and roundabouts.