[afr0ck]

Linux kernel is not complex. Most of the code runs lock-free. For example, the slab allocator in the kernel uses only a single double_cmpxhg instruction to allocate an object via kmalloc(). The algorithm scales to any number of CPUs and has NUMA awareness. Basically, the most concurrent, lowest allocation latency allocator you can get in the market, which also returns the best objects for the requesting process on big memory systems.

The complexity on the other hand is architectural and logical to achieve scale to hundreds of CPUs, maximise bandwidth and reduce latency as much as possible.

Any normal Rust kernel will either have issues scaling on multi-cores or use tax-heavy synchronisation primitives. The kernel RCU and lock-free algorithm took a long time to be discovered and become mature and optimised aggressively to cater for the complex modern computer architectures of out-of-order execution, pipelining, complex memory hierarchies (especially when it comes to caching) and NUMA.

[ladyanita22]

> Any normal Rust kernel will either have issues scaling on multi-cores or use tax-heavy synchronisation primitives. The kernel RCU and lock-free algorithm took a long time to be discovered and become mature and optimised aggressively to cater for the complex modern computer architectures of out-of-order execution, pipelining, complex memory hierarchies (especially when it comes to caching) and NUMA.

Why would that be the case at all? What has Rust anything to do with that?

[sshine]

A new kernel can never beat legacy kernels on hardware support.

To reach a useful state, you only need to be highly performant on a handful of currently popular server architectures.

> Any normal Rust kernel will either have issues scaling on multi-cores or use tax-heavy synchronisation primitives.

I'm not sure how that applies to Asterinas. Is Asterinas any normal Rust kernel?

https://asterinas.github.io/book/kernel/the-framekernel-arch...