This is nicely moving down the stack from some other nearby work. ByteDance just released code for Parker, a Linux multi-kernel approach where each core gets its own copy of Linux (and there's one coordinator core). There's another more general multi-kernel on one system approach that also has been quite active recently, that's more general (not strictly 1:1 cores kernel). https://www.phoronix.com/news/Linux-Parker-Proposal https://www.phoronix.com/news/Multi-Kernel-Linux-v2
(Obviously we can and do do lots of single thread per core work already: these emerging multi-kernel ideas are trying to push new territory, new isolation, eliminate yet more contention.)
Personally, I would never agree to give up SMP CPU coherency. Multiprocessor systems are hard enough to debug with hardware cache coherency that adding in entirely new unpredictable non-deterministic behaviour would lead to more developers losing the rest of their hair prematurely. And it would likely introduce an entirely new class of security issues that nobody ever imagined that would require even worse performance draining software workarounds.
Some things are best done in hardware.
> Personally, I would never agree to give up SMP CPU coherency. Multiprocessor systems are hard enough to debug with hardware cache coherency that adding in entirely new unpredictable non-deterministic behaviour would lead to more developers losing the rest of their hair prematurely. And it would likely introduce an entirely new class of security issues that nobody ever imagined that would require even worse performance draining software workarounds.
What are you envisioning is the alternative hardware (or is it software?), and why? I assume this is referring to some mechanism for multikernel support that doesn't rely on cache coherence. It seems like there are probably alternatives to full cache coherence that would be neutral, or better, after experience. You didn't provide substantive evidence, but on the other hand, at least multikernels on unmodified hardware seem promising.
(And did Maddog (DEC) with a different set of experiences agree?)
Linux would benefit from a scheduler per CCD (in AMD parlance) approach being a first-class option. CCD pinning is a mechanism to push in this direction today, but partitioning kernel scheduler(s) along hardware boundaries would reduce complexity and overhead for a lot of use cases..
fanf2•3mo ago
https://phk.freebsd.dk/sagas/phkmalloc/
https://cgit.freebsd.org/src/tree/lib/libc/stdlib/malloc.c?h...