Hacker News Reader

Comment by nijave | Hacker News Reader

Couldn't you just boot the Linux kernel directly and launch a generic app as pid 1 instead of a full blown init system with a bunch of daemons?

That's basically what you're getting with Docker containers and a shared kernel. AWS Lambda is doing something similar with dedicated kernels with Firecracker VMs

View on HN

Yes, you can. You can even have a different Pid 1 configure whatever and then replace it's core image with the new Pid 1.

Yes, but I wanted to bypass having the complexity of the Linux kernel completely, too.

Basically single app directly to network (the world) and as little as possible else in between.

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.

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...

> 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?

Reply on news.ycombinator.com