← Back to context

Comment by csb6

6 hours ago

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.

      5 replies →

    • 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 )

      1 reply →

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.