Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Gnu/Hurd strikes back: How to use the legendary OS in a (somewhat) practical way

mhatta.medium.com

Post reply on HN
Print view View original

121–130 of 273 posts

Re: Gnu/Hurd strikes back: How to use the legendary OS in a (somewhat) practical way

#121

Post by darksaints »

dralley wrote: post #101
darksaints wrote: post #85

Earlier quoted context omitted.

Linux IPC syscall latencies benchmark in the 10s of microseconds typically. SeL4 has worst case execution guarantees that are better than that, even counting the fact that you have to do two syscalls for every one Linux syscall. We’re talking less than a thousand cycles total, which would be less than a single microsecond. https://www.sel4.systems/About/Performance/home.pml

Does SeL4 have all of of the speculative execution mitigations that Linux has? Syscall latency also is not the end-all-be-all of performance. Does that actually translate to faster disk and socket I/O on average?

I do believe there are speculative execution mitigations, yes...and from what I remember there was a significant performance impact when they were implemented, and especially so on processors without dedicated code caches.

Syscall latency is definitely not the end-all-be-all of performance, but it is all there is to compare between a monolithic kernel and a microkernel. In both cases, driver code needs to run, and that driver code can be good or shitty just like everything else.

When it comes down to it, the syscall latency that is comparable is the context switch between privileged and unprivileged mode. The holy grail of microkernels isn't to be faster than macrokernels, it is to be just as fast, but a hell of a lot more modular, usable, and secure.

Re: Gnu/Hurd strikes back: How to use the legendary OS in a (somewhat) practical way

#122

Post by PaulDavisThe1st »

winter_blue wrote: post #108
weberer wrote: post #78

Earlier quoted context omitted.

Yes, its mostly drivers. Here's a breakdown of the Linux kernel by lines of code: https://upload.wikimedia.org/wikipedia/commons/f/f5/Sankey_D...

Wow, I'm surprised by how small the file systems are. On the smaller side, Ext4 at just 21,515 lines, and on the larger side, Btrfs at 55,758 lines. It almost makes me think that writing a new file system in Rust, might actually be a tractable project.

[flagged]

Re: Gnu/Hurd strikes back: How to use the legendary OS in a (somewhat) practical way

#123

Post by Nereuxofficial »

winter_blue wrote: post #108
weberer wrote: post #78

Earlier quoted context omitted.

Yes, its mostly drivers. Here's a breakdown of the Linux kernel by lines of code: https://upload.wikimedia.org/wikipedia/commons/f/f5/Sankey_D...

Wow, I'm surprised by how small the file systems are. On the smaller side, Ext4 at just 21,515 lines, and on the larger side, Btrfs at 55,758 lines. It almost makes me think that writing a new file system in Rust, might actually be a tractable project.

I also thought that'd be a fun project. BTRFS seems to have the largest feature set although many features are experimental but maybe there would be a place for something smaller that scales well and maybe has some of the new features like deduplication

Re: Gnu/Hurd strikes back: How to use the legendary OS in a (somewhat) practical way

#125

Post by rjsw »

boricj wrote: post #63
AdmiralAsshat wrote: post #27

Earlier quoted context omitted.

Could one not make the case that maybe device driver support doesn't belong in the kernel itself?

NetBSD has architectured their drivers to be basically static archives reusable anywhere. It's part of the NetBSD rump kernel.

The drivers are not used in that way in NetBSD, they are either compiled into the kernel or built as modules just like in Linux, the graphics drivers even use the source code from Linux.

Re: Gnu/Hurd strikes back: How to use the legendary OS in a (somewhat) practical way

#126

Post by darksaints »

twic wrote: post #79
darksaints wrote: post #30

Earlier quoted context omitted.

I understand what you're saying, but both are true. 1. Linux is too big. Even if we exclude the drivers, which are a majority of the kernel codebase, linux is still a massive kernel. Most microkernels are small enough to fit in the L3 cache, some are small enough to fit in the L2 cache. Linux, even if we could exclude the drivers, doesn't even come close. This inability to fully cache the kernel ends up negating the…

> Most microkernels are small enough to fit in the L3 cache, some are small enough to fit in the L2 cache. Linux, even if we could exclude the drivers, doesn't even come close. This inability to fully cache the kernel ends up negating the primary benefit that monolithic kernels have, which is performance. Linux spends more time bouncing around the cache than a modern microkernel takes to do an extra syscall. This mak…

You're right...that is the part that doesn't matter. But the kernel still has to coordinate and schedule that. The kernel has an inherent overhead for execution and context switching, and will always have some amount of code that is hot.

The reason microkernels typically benchmark on syscall (typically IPC) latency is because that is the only truly apples to oranges part that you can't compare between the two. Monolithic kernels have a single context switch, microkernels have two. But microkernels, being micro, are a lot friendlier to caches (less to load and flush), and especially so with dedicated code caches (which do not need to flush on context switch).

Re: Gnu/Hurd strikes back: How to use the legendary OS in a (somewhat) practical way

#127

Post by actionfromafar »

ssrc wrote: post #62
ye-olde-sysrq wrote: post #29

Earlier quoted context omitted.

Isn't this this mono vs micro kernel debate all over again?

I think it's monorepo vs multi-repo, and since Linux maintainers update the drivers (I believe) when internal APIs change, and the internal APIs are not stable, monorepo seems more practical.

Maybe I’m missing the joke, but in or out of kernel context is orthogonal to how the source code is stored.

Re: Gnu/Hurd strikes back: How to use the legendary OS in a (somewhat) practical way

#128

Post by meepmorp »

PaulDavisThe1st wrote: post #122
winter_blue wrote: post #108

Earlier quoted context omitted.

Wow, I'm surprised by how small the file systems are. On the smaller side, Ext4 at just 21,515 lines, and on the larger side, Btrfs at 55,758 lines. It almost makes me think that writing a new file system in Rust, might actually be a tractable project.

[flagged]

It's a good thing that you warned them off, or they might've accidentally gone and done something interesting or enjoyable.

Re: Gnu/Hurd strikes back: How to use the legendary OS in a (somewhat) practical way

#129

Post by jonhohle »

actionfromafar wrote: post #127
ssrc wrote: post #62

Earlier quoted context omitted.

I think it's monorepo vs multi-repo, and since Linux maintainers update the drivers (I believe) when internal APIs change, and the internal APIs are not stable, monorepo seems more practical.

Maybe I’m missing the joke, but in or out of kernel context is orthogonal to how the source code is stored.

The author is the same (Linus), so it makes sense that he would design a source control system that supported the monorepo he created over the prior 15-ish years.

Re: Gnu/Hurd strikes back: How to use the legendary OS in a (somewhat) practical way

#130

Post by einpoklum »

boricj wrote: post #63
AdmiralAsshat wrote: post #27

Earlier quoted context omitted.

Could one not make the case that maybe device driver support doesn't belong in the kernel itself?

NetBSD has architectured their drivers to be basically static archives reusable anywhere. It's part of the NetBSD rump kernel.

What do you mean by "reusable everywhere"? I mean, where could they be used other than in a NetBSD kernel?
Post reply on HN