4 ms·

Linux has plenty of engineering. Of course that doesn't mean identical features. Linux has a VFS with lockless path lookups. The push to get Linux running on m

by burfog 7y ago

Linux has plenty of engineering. Of course that doesn't mean identical features. Linux has a VFS with lockless path lookups. The push to get Linux running on machines like the SGI Altix, with at least 10240 cores running one shared instance of the kernel, has really helped with locking issues. Another factor has been the push for real-time performance, with and without choosing the option to make the kernel preemptable.

snvzz 7y ago
And all of this is based on hacks and ugly workarounds, due to the kernel being a monolithic design. When the kernel isn't monolithic, kernel preemption isn't necessary, or worth it[0]. Imagine if instead of the, I argue insane, complexity added by the fine-grained SMP locks and the unholy mess that is kernel preemption, the kernel had been split into separate processes, which maps to SMP cleanly. Actually, I don't have to imagine it, because that's what Dragonfly has been progressively doing since they forked FreeBSD, and what microkernel multiserver systems like Genode/seL4 or HelenOS are from the get-go. It turns out, despite having very little manpower (which is why they chose to focus on x86-64), Dragonfly has performance and scalability competitive to Linux today. Imagine if they had more people. I will not be too surprised when Dragonfly finally leaves Linux in the dust and people wonder how the hell, which is something I predict will happen. Linux hit a ceiling despite all the money thrown into it. Dragonfly hasn't yet. [0]: http://ts.csiro.au/publications/nicta_full_text/5859.pdf http://ts.csiro.au/publications/nicta_full_text/5859.pdf
- dntbnmpls 7y ago
  > And all of this is based on hacks and ugly workarounds, due to the kernel being a monolithic design. But most BSD ( including OpenBSD which you just praised ) is monolith as well. > I will not be too surprised when Dragonfly finally leaves Linux in the dust and people wonder how the hell, which is something I predict will happen. Dragonfly would have to first leave FreeBSD in the dust before taking on all the linux distros. Microkernels are great for learning about kernels. Monoliths have been great for general and corporate use. Perhaps the future is hybrid, only time will tell.
  - snvzz 7y ago
    >Dragonfly would have to first leave FreeBSD in the dust before taking on all the linux distros. You're late to the party, as Dragonfly is already outdoing Linux in some areas, such as the network stack[0]. >But most BSD ( including OpenBSD which you just praised ) is monolith as well. I praised them for the engineering they've been doing. They still retain flexibility, despite the monolithic design. Linux went all-in with their smp locking and kernel preemption, and the costs of getting any work done on the source code have skyrocketed since. >Perhaps the future is hybrid, only time will tell. Hybrid is a marketing term. It's a blurry line between a monolith and a so-called hybrid. What they're marketing is structure. Structure is good. Netbsd is an example of a well structured system. Linux is the counterpart: A poorly structured one. >Monoliths have been great for general and corporate use. UNIX is an old design. Corporate hates taking risks. However, there's massive scale deployments of microkernel systems, they're just not on your face; the visibility is actually quite low for these. But they do tasks that greatly benefit from or outright require such a design. Monolithic design limits are more evident than ever, as we're hitting them left and right. So this is changing. For instance, besides systems such as Genode and HelenOS, Google is working on Fuchsia and Huawei on HarmonyOS. Brace for impact, as waves will be made when this all finally hits. [0]: https://leaf.dragonflybsd.org/~sephe/perf_cmp.pdf https://leaf.dragonflybsd.org/~sephe/perf_cmp.pdf
    - jayp1418 7y ago
      Maybe rump kernels might be future : https://research.csiro.au/tsblog/using-rump-kernels-to-run-unmodified-netbsd-drivers-on-sel4/ https://research.csiro.au/tsblog/using-rump-kernels-to-run-u...
      - snvzz 7y ago
        It's amusing you mention this. I just used the rump implementation of fat filesystem (rump_msdos) to mount a fat floppy on netbsd on an Amiga with a kernel where I didn't build msdos support in.
- asveikau 7y ago
  I don't mean to be impolite and I am a BSD fan but you are just trolling here. Lock free path lookups are not a hack. It is a pretty amazing feat IMO. And the fact that it is done for all filesystems transparently in the VFS layer ... You couldn't do that on the Windows NT kernel for example (a microkernel design), because every filesystem driver has to figure out its own path logic there. Linux isn't known for good design all the time but it is a good design.
  - snvzz 7y ago
    >the Windows NT kernel for example (a microkernel design) Windows NT isn't a microkernel design. It does however have some structure to it. Some call it Hybrid kernel, I call it crude layering. It's still better than the spaghetti Linux is. >you couldn't do it Each approach has different tradeoffs. With the microkernel multiserver approach, you get a lot of advantages, such as having a tiny amount of code running in supervisor mode, having strong separation enforced by it, particularly if using the capability model (not to be confused with POSIX capabilities). Possibly formally proven like seL4. It is possible to build a secure system on such a design. It is also possible to build a hard realtime (with proven WCET). It is not possible to do either with a monolith, because of the impossibility of proving the correctness of the monolith inherent to its sheer size and the exponential nature of verification work. In detriment, there's more context switches, which have a cost. But this cost is an order of magnitude smaller on seL4 than Linux, for a solid example. You'd need a severe amount of extra context switches for an actual performance penalty. And seL4 would still have a massive advantage in latency. >but you are just trolling here. No, I am not, and I do not appreciate the accusation. Try and be kind.
    - asveikau 7y ago
      You don't have to explain microkernels to me, I know how they work. You could replicate the advantages I describe of path caching in Linux VFS in a microkernel by having some kind of common VFS server, or perhaps write the VFS layer as a library that filesystems consume. This is because micro vs. monolithic is an orthogonal choice to the design. The fact that it has not chosen your favorite approach on that unrelated axis does not make it bad.

by burfog 7y ago

snvzz 7y ago

And all of this is based on hacks and ugly workarounds, due to the kernel being a monolithic design. When the kernel isn't monolithic, kernel preemption isn't necessary, or worth it[0]. Imagine if instead of the, I argue insane, complexity added by the fine-grained SMP locks and the unholy mess that is kernel preemption, the kernel had been split into separate processes, which maps to SMP cleanly. Actually, I don't have to imagine it, because that's what Dragonfly has been progressively doing since they forked FreeBSD, and what microkernel multiserver systems like Genode/seL4 or HelenOS are from the get-go. It turns out, despite having very little manpower (which is why they chose to focus on x86-64), Dragonfly has performance and scalability competitive to Linux today. Imagine if they had more people. I will not be too surprised when Dragonfly finally leaves Linux in the dust and people wonder how the hell, which is something I predict will happen. Linux hit a ceiling despite all the money thrown into it. Dragonfly hasn't yet. [0]: http://ts.csiro.au/publications/nicta_full_text/5859.pdf http://ts.csiro.au/publications/nicta_full_text/5859.pdf

dntbnmpls 7y ago
> And all of this is based on hacks and ugly workarounds, due to the kernel being a monolithic design. But most BSD ( including OpenBSD which you just praised ) is monolith as well. > I will not be too surprised when Dragonfly finally leaves Linux in the dust and people wonder how the hell, which is something I predict will happen. Dragonfly would have to first leave FreeBSD in the dust before taking on all the linux distros. Microkernels are great for learning about kernels. Monoliths have been great for general and corporate use. Perhaps the future is hybrid, only time will tell.
- snvzz 7y ago
  >Dragonfly would have to first leave FreeBSD in the dust before taking on all the linux distros. You're late to the party, as Dragonfly is already outdoing Linux in some areas, such as the network stack[0]. >But most BSD ( including OpenBSD which you just praised ) is monolith as well. I praised them for the engineering they've been doing. They still retain flexibility, despite the monolithic design. Linux went all-in with their smp locking and kernel preemption, and the costs of getting any work done on the source code have skyrocketed since. >Perhaps the future is hybrid, only time will tell. Hybrid is a marketing term. It's a blurry line between a monolith and a so-called hybrid. What they're marketing is structure. Structure is good. Netbsd is an example of a well structured system. Linux is the counterpart: A poorly structured one. >Monoliths have been great for general and corporate use. UNIX is an old design. Corporate hates taking risks. However, there's massive scale deployments of microkernel systems, they're just not on your face; the visibility is actually quite low for these. But they do tasks that greatly benefit from or outright require such a design. Monolithic design limits are more evident than ever, as we're hitting them left and right. So this is changing. For instance, besides systems such as Genode and HelenOS, Google is working on Fuchsia and Huawei on HarmonyOS. Brace for impact, as waves will be made when this all finally hits. [0]: https://leaf.dragonflybsd.org/~sephe/perf_cmp.pdf https://leaf.dragonflybsd.org/~sephe/perf_cmp.pdf
  - jayp1418 7y ago
    Maybe rump kernels might be future : https://research.csiro.au/tsblog/using-rump-kernels-to-run-unmodified-netbsd-drivers-on-sel4/ https://research.csiro.au/tsblog/using-rump-kernels-to-run-u...
    - snvzz 7y ago
      It's amusing you mention this. I just used the rump implementation of fat filesystem (rump_msdos) to mount a fat floppy on netbsd on an Amiga with a kernel where I didn't build msdos support in.
asveikau 7y ago
I don't mean to be impolite and I am a BSD fan but you are just trolling here. Lock free path lookups are not a hack. It is a pretty amazing feat IMO. And the fact that it is done for all filesystems transparently in the VFS layer ... You couldn't do that on the Windows NT kernel for example (a microkernel design), because every filesystem driver has to figure out its own path logic there. Linux isn't known for good design all the time but it is a good design.
- snvzz 7y ago
  >the Windows NT kernel for example (a microkernel design) Windows NT isn't a microkernel design. It does however have some structure to it. Some call it Hybrid kernel, I call it crude layering. It's still better than the spaghetti Linux is. >you couldn't do it Each approach has different tradeoffs. With the microkernel multiserver approach, you get a lot of advantages, such as having a tiny amount of code running in supervisor mode, having strong separation enforced by it, particularly if using the capability model (not to be confused with POSIX capabilities). Possibly formally proven like seL4. It is possible to build a secure system on such a design. It is also possible to build a hard realtime (with proven WCET). It is not possible to do either with a monolith, because of the impossibility of proving the correctness of the monolith inherent to its sheer size and the exponential nature of verification work. In detriment, there's more context switches, which have a cost. But this cost is an order of magnitude smaller on seL4 than Linux, for a solid example. You'd need a severe amount of extra context switches for an actual performance penalty. And seL4 would still have a massive advantage in latency. >but you are just trolling here. No, I am not, and I do not appreciate the accusation. Try and be kind.
  - asveikau 7y ago
    You don't have to explain microkernels to me, I know how they work. You could replicate the advantages I describe of path caching in Linux VFS in a microkernel by having some kind of common VFS server, or perhaps write the VFS layer as a library that filesystems consume. This is because micro vs. monolithic is an orthogonal choice to the design. The fact that it has not chosen your favorite approach on that unrelated axis does not make it bad.