4 ms·

Mot less code to implement, but it modularizes logic such that it's (theoretically) trivial to disable unneeded features. I'm sure the majority of that Linux ke

by m0th87 17y ago

Mot less code to implement, but it modularizes logic such that it's (theoretically) trivial to disable unneeded features. I'm sure the majority of that Linux kernel logic is never executed; if that code were instead placed in user-level processes, they would have no performance hit. There are a lot of other side benefits. As stable as Linux is, it still has a great deal of code executing in kernel mode, which is error-prone; microkernels can restart crashed processes on-the-fly without compromising the stability of the system rather easily. Also, some of the newer microkernels have formal proofs of their security properties, which is pretty damn fascinating! (albeit they assume the underlying proof system itself is error-free, which might not be true)

deleted 17y ago
[deleted]
Tuna-Fish 17y ago
As anyone who has ever run Kconfig knows, linux is already very well modularized, and disabling unneeded logic at compile time is already easy, and most of the kernel actually resides in dynloaded modules these days. > I'm sure the majority of that Linux kernel logic is never executed; if that code were instead placed in user-level processes, they would have no performance hit. Such code doesn't matter. Most of it is in a dynloaded module, so it doesn't even eat ram, and even the stuff baked in the kernel hardly matters for performance -- the < 5 megabytes of ram doesn't even hurt in cellphones anymore, and the thing that hurts most is L1i cache use, where only code that is actually executed goes. The bloat we are talking about is not the increase in the total size of the kernel, but the increase of the size of the commonly executed code paths. Linux being a microkernel would not help there, in fact it would hurt.
- fauigerzigerk 17y ago
  An increase of the size of commonly executed code paths could mean two things. First, it could mean that a lot of special casing has accumulated due to lack of modularisation or cleanup work. Or it could mean that these cases do in fact have to be considered on that code path every time and that any "outsourcing" to user mode processes would in fact increase the size of the code path. If it's the former, then the argument that a micro kernel design encourages more fine grained modularisation and leads to fewer special cases is not completely spurious in my opinion. But all of this is impossible to judge without looking at the code itself.
  - tensor 17y ago
    Said in a simpler way: either Linux is poorly designed, or that amount of code is necessary for a general purpose kernel. This assumes that someone needs and actively maintains every feature in the code.
    - Tuna-Fish 17y ago
      > either Linux is poorly designed I take offense at the statement "Linux is designed" :) Of course it is not optimal. Nothing else is either. How can we make it better?
- dkarl 17y ago
  As anyone who has ever run Kconfig knows, linux is already very well modularized, and disabling unneeded logic at compile time is already easy Yet in the interview, Linus says the kernel is getting bigger and slower because of new features, which presumably not everybody needs. "[W]e are definitely not the streamlined, small, hyper-efficient kernel that I envisioned 15 years ago...The kernel is huge and bloated, and our icache footprint is scary. I mean, there is no question about that. And whenever we add a new feature, it only gets worse." He isn't talking about code that can be compiled out or left unloaded if you don't need it. He's talking about code that ends up in your instruction cache whether you need the features or not.

by m0th87 17y ago

deleted 17y ago

[deleted]

Tuna-Fish 17y ago

As anyone who has ever run Kconfig knows, linux is already very well modularized, and disabling unneeded logic at compile time is already easy, and most of the kernel actually resides in dynloaded modules these days. > I'm sure the majority of that Linux kernel logic is never executed; if that code were instead placed in user-level processes, they would have no performance hit. Such code doesn't matter. Most of it is in a dynloaded module, so it doesn't even eat ram, and even the stuff baked in the kernel hardly matters for performance -- the < 5 megabytes of ram doesn't even hurt in cellphones anymore, and the thing that hurts most is L1i cache use, where only code that is actually executed goes. The bloat we are talking about is not the increase in the total size of the kernel, but the increase of the size of the commonly executed code paths. Linux being a microkernel would not help there, in fact it would hurt.

fauigerzigerk 17y ago
An increase of the size of commonly executed code paths could mean two things. First, it could mean that a lot of special casing has accumulated due to lack of modularisation or cleanup work. Or it could mean that these cases do in fact have to be considered on that code path every time and that any "outsourcing" to user mode processes would in fact increase the size of the code path. If it's the former, then the argument that a micro kernel design encourages more fine grained modularisation and leads to fewer special cases is not completely spurious in my opinion. But all of this is impossible to judge without looking at the code itself.
- tensor 17y ago
  Said in a simpler way: either Linux is poorly designed, or that amount of code is necessary for a general purpose kernel. This assumes that someone needs and actively maintains every feature in the code.
  - Tuna-Fish 17y ago
    > either Linux is poorly designed I take offense at the statement "Linux is designed" :) Of course it is not optimal. Nothing else is either. How can we make it better?
dkarl 17y ago
As anyone who has ever run Kconfig knows, linux is already very well modularized, and disabling unneeded logic at compile time is already easy Yet in the interview, Linus says the kernel is getting bigger and slower because of new features, which presumably not everybody needs. "[W]e are definitely not the streamlined, small, hyper-efficient kernel that I envisioned 15 years ago...The kernel is huge and bloated, and our icache footprint is scary. I mean, there is no question about that. And whenever we add a new feature, it only gets worse." He isn't talking about code that can be compiled out or left unloaded if you don't need it. He's talking about code that ends up in your instruction cache whether you need the features or not.