This kind of approach is being used also by software enclaves for security reasons. Cache sharing (or side channels derived from shared state in general) is a way for leaking memory contents and a vector for different attacks. Isolation is much better: you don't share cores (and you share less of the memory hierarchy) with the kernel and the communication channel has natural choke points.
- curiosity sKilled the cat On Wed, Sep 2, 2026, 20:51 Paul Lalonde <[email protected]> wrote: > You gain *consistency*. Your TLB entries don't get messed up, your branch > predictor doesn't get clobbered, you don't mysteriously lose 1.5M clocks > every once in a while, etc. > > Paul > > On Wed, Sep 2, 2026, 10:32 a.m. Edouard Klein <[email protected]> wrote: > >> My understanding of the benefits is that by removing interrupts and >> context switching you gain a surprising amount of performance for >> userspace tasks, each of which gets a basically dedicated core from >> start to finish (with all its cache). Is that correct ? >> >> >> Ron Minnich <[email protected]> writes: >> >> > from a book: >> > >> > "The NIX project targeted manycore architectures in which only a small >> > subset of the cores could run kernel code. Consider N cores on a die >> > arranged in a grid, with an on-die network providing a totally >> > symmetric network and access to common memory. Let us assume that only >> > of the cores can run a kernel and the rest can only run user mode >> > code. NIX was intended to provide a kernel for such a system. The >> > hypothetical target was a 1,024 core system, as several vendors hinted >> > that was reasonable in the 2016 time frame. We picked this number as >> > it was large enough to far exceed any possible number of user >> > processes: the Plan 9 systems on which NIX was based use only a small >> > fraction of this number. Further, the realities of memory bandwidth >> > will limit the number of active cores to small single digits. We also >> > wanted to have a system with good support for Go, the then-new >> > language from Google. At the time, Go was a statically linked language >> > and a typical binary was about 1 MiB. This influenced the design of >> > the virtual memory system in NIX. The base page size was expanded from >> > 4,096 bytes to 2 MiB. We further extended Plan 9’s virtual memory >> > model to transparently support GiB pages, but via a simple heuristic >> > that made it far less complex than existing systems. The target system >> > had a 32:1 ratio of application cores to kernel cores (a close match >> > to the Blue Gene/Q system at 16:1), and it was designed for space >> > sharing, not time sharing, and had a minimum page size of 2 MiB; >> > supported GiB pages; and yet, at the same time, looked in all other >> > ways like a standard Plan 9 system." >> > >> > >> > note that the Esperanto system, released in 2017 or so, closely >> > matches this model, as do other risc-v systems. I have a few of these >> > cards, so may take a look at whether it might work. >> > >> > On Tue, Sep 1, 2026 at 1:38 PM <[email protected]> wrote: >> >> >> >> For context, what was NIX? How did it differ from Plan 9 4th edition? >> What were the goals? >> >> 9fans / 9fans / see discussions + participants + delivery options >> Permalink > *9fans <https://9fans.topicbox.com/latest>* / 9fans / see discussions > <https://9fans.topicbox.com/groups/9fans> + participants > <https://9fans.topicbox.com/groups/9fans/members> + delivery options > <https://9fans.topicbox.com/groups/9fans/subscription> Permalink > <https://9fans.topicbox.com/groups/9fans/Ta20bdef5171bc207-Mcfd0373e764911ef1a1ee294> > ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Ta20bdef5171bc207-M3a9f19573625d479bbd38e33 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
