I found the original 2011 paper, which was a sandia report, from may 2011. It's a modification of the original proposal, which I no longer have; but it is a good summary of where we were at the end of my visit in May.
This is interesting: "We have changed a surprisingly small amount of code at this point. There are about 400 lines of new assembler source, about 80 lines of platform independent C source, and about 350 lines of AMD64 C source code. To this, we have to add a few extra source lines in the start-up code, system call, and trap han- dlers. This implementation is being both developed and tested only in the AMD64 architecture." I uploaded it to the Plan 9 foundation shared drive: https://drive.google.com/file/d/1F41_4MFpio3UsnxOpTJBiypUrHjkinL-/view?usp=share_link On Tue, Jan 7, 2025 at 10:18 AM <tlaro...@kergis.com> wrote: > > On Tue, Jan 07, 2025 at 09:20:06AM -0800, Ron Minnich wrote: > > > > Why NIX? > > > > If you think about it, timesharing is designed for a world where cores > > are scarce. But on a machine with hundreds of cores, running Plan 9, > > there are < 100 processes. We can assign a core to each process, and > > let those processes own the core until they are done. This might be a > > useful simplification, it might not, but it's something. > > > > I did run some standard HPC benchmarks on NIX ACs and the results were > > good. I was always curious how it would work if we had those > > multi-hundred-core machines Intel and IBM and others were telling us > > about in 2011. Now that we have them, it would be interesting to try. > > As said previously, I will start wandering and stumbling upon problems > this week-end---I'm a toddler in the area, so it's the way to learn to > walk. > > But this brief summary highlight a solution and questions > that are, IMHO, valid questions: remember the "war" between > "micro-kernels" and "monolithic kernels"? In Unix, the kernel is not a > separate process (well: there are "administrative" processes, > scheduler and pager but...) but part of the applications. This is also > why it is efficient compared to "message passing" micro-kernels that > are not "near" enough the hardware---so inefficient that, for > ideologic purposes, some have rewritten "micro-kernels" in assembly to > improve the result... > > But multiple cores (and even in the smaller machines nowadays, you > find two) present another mean of articulation of the OS code (the > MMU is central for me in the whole picture: not move the data > around, but change the view of the shared data per core). The question > is at least certainly worth asking. > > -- > Thierry Laronde <tlaronde +AT+ kergis +dot+ com> > http://www.kergis.com/ > http://kertex.kergis.com/ > Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T7692a612f26c8ec5-M466cceae3c3bc516f71a077b Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
