Does anyone more familiar with Hurd know how they addressed performance issues encountered by other Mach-based kernels? I remember reading that one of Mach's bottlenecks was validating that each IPC message had proper permissions/access when sending them between processes due to the large number and frequency of messages.
Mach's problem wasn't that it had slow IPC, but rather that in terms of microkernels, Mach was pretty damn big.
There are some very fast microkernels out there, like the L4 family, which negate the IPC overhead of microkernels by being small enough to fit entirely in the L2 cache of most processors. Linux may only have the single IPC call per round trip, but it's a fucking huge kernel and there is typically a ton of cache thrashing going on.
>small enough to fit entirely in the L2 cache
Shouldn't the "hot" path fit in the L1 of a "modern" processor (100 kB+)?
Are you saying there is cache thrashing because callers often sercice rheid own requests themselves? If you don't want to service requests in the same thread, doesnt it mean you have to spend entire core(s) for running the kernel?
Is that a bottleneck anymore? Maybe something that was appreciable in 1994 isn't a big performance hit in 2026?
Yes, you want to do more IPC, its basically linear with the increase in performance. So the amount of overhead stays the same basically. At least in IPC benchmarks and those tend to be important.
Making that fast is fundamental to any OS.
So for an I/O heavy program like a web browser, what percentage of CPU time is spent in syscalls? Someone must have that data for Firefox. 1%? 10%? And then that moves to 1.1% (or 11%)? And then every other program is even less affected? Curious if anyone is in the know.
Isn't it even worse now? The faster computers get, the more that software-induced bottlenecks hurt.
I could see just powering through because modern hardware is fast enough to do so being an option.
Adding 20% to a 10 second operation is a lot longer on a wall clock than adding 20% to a 1 second operation.
What even is a 20% delta in performance? Like a five year old difference in hardware design.
If I could get a micro kernel with a better security profile than Linux, that doesn’t sound so bad. I could easily be using a ten year old chip for my day to day browsing and probably wouldn’t notice.
Hurd is like 36 years old at this point. More like adding 20% to a 10 second operation, compared to adding 20% to a 10ms operation.
If anything, Mach style IPC has gotten worse because of the greater overhead if kernel/user transitions. Spectre really did a number on context switching overhead.
People lost their shit when Spectre mitigations added 20% overhead to kernel calls though. Why wouldn't they do the same for microkernel overhead?
If people really cared about performance, we'd be doing something other than the bloated way we have been doing things.
https://winworldpc.com/product/qnx/144mb-demo
I'm not a Hurd contributor ( or any OS kernel / library ).
I'm not sure this holds today. One example I can see is related to crypto. We used to have specific hardware for computing cryptography functions but it's now handled directly in standard hardware and the software has not evolved ( but it's been faster and faster to compute checksum functions )
I mean, every major arch has crypto specific acceleration instructions.
Is there reason to think they've addressed them?
Lets get to a usable feature set before optimization.
This is what I like about Haiku OS, they have focused a lot functionality and have that fairly solid, now optimization and stability is being worked on more closely.