# Implementing fork() on the Mill CPU

DevFeed: [Implementing fork() on the Mill CPU](<https://devfeed.tech/articles/implementing-fork-on-the-mill-cpu-21567.md>)

Original publisher: [Read original article](<http://lackingrhoticity.blogspot.com/2014/07/implementing-fork-on-mill-cpu.html>)

Author: Mark Seaborn (noreply@blogger.com)

Published: 2014-07-23T03:12:00Z

Content type: article

Language: en

Sources: [Mark Seaborn](<https://devfeed.tech/sources/mark-seaborn.md>)

Topics: [cpu](<https://devfeed.tech/topics/cpu.md>), [Processes](<https://devfeed.tech/topics/processes.md>), [Unix](<https://devfeed.tech/topics/unix.md>), [systems](<https://devfeed.tech/topics/systems.md>)

Tags: [architecture](<https://devfeed.tech/tags/architecture.md>), [cache](<https://devfeed.tech/tags/cache.md>), [cpu](<https://devfeed.tech/tags/cpu.md>), [performance](<https://devfeed.tech/tags/performance.md>), [processes](<https://devfeed.tech/tags/processes.md>), [unix](<https://devfeed.tech/tags/unix.md>)

## AI overview

This article examines how the Mill CPU architecture might implement Unix fork(). It explains the architecture's Single Address Space OS model and speculates that forked processes could require flushing affected TLB and cache ranges during context switches. The performance impact would depend on the Mill's cache and TLB design, while copy-on-write and the typical short lifetime of forked processes could limit the cost.

## Source excerpt

The Mill is a new CPU architecture that claims to provide high performance but at a much better performance-per-watt than conventional CPUs that use out-of-order execution. The Mill achieves this by making various architectural simplifications. One of those is to remove the TLB from the fast path of memory accesses. Rather than having the TLB between the CPU core and the cache, the Mill's TLB is between the cache and main memory. OS models This means the Mill is best suited for running Single Address Space operating systems (SASOS). The intent is that different processes will live at different addresses within a shared 64-bit address space. A process runs with permissions to access restricted ranges of this address space. Switching between processes is therefore just a matter of switching those permissions, which is fast on the Mill. It doesn't involve an expensive flush of the TLB (as on a conventional OS). It doesn't involve flushing the Mill's virtual-address-tagged (VIVT) cache. This runs into a problem if we want to run Unix programs that use fork(), though. Use of fork() assumes that multiple processes will want to use the same virtual addresses. The Mill developers have said they have a scheme for handling fork(), but they haven't said what it is, so I'm going to speculate. :-) Context switching If you create forked processes that share a range of virtual address space, a Mill OS can just flush the TLB and cache for those ranges whenever it needs to context switch between the two processes. Basically, a Mill OS can act like a Separate Address Space OS when handling forked processes. Switching costs How expensive that would be depends on how the TLB and cache work. In conventional CPUs, the TLB is per-core. The Mill's TLB might be shared between cores, though, if the Mill has higher-level caches that are both virtually-tagged and shared between cores. If that's the case, forked processes wouldn't be able to run concurrently on multiple cores. Flushing the TLB