I wonder what this means exactly
|
| Author | Content |
|---|---|
| montezuma Sep 22, 2009 9:31 AM EDT |
Bottomley refers to an internal Intel benchmark which I assume amounts to a test of each kernel with all the default kernel switches set. From my experience of compiling the kernel there is an awful lot of choice there (intimidatingly in fact). So I am wondering if you were so inclined and technically competent enough, could you run through this compilation process and turn off most of the bloat? Or is Linus actually saying that the basic bare bones part of the kernel is becoming bloated because of the free for all nature of how contributions are assembled? Would be interesting to know where the biggest problem was. I suspect with no evidence that it is all the options being turned on to handle the ever increasing diversity of modern hardware but that is a guess on my part. |
| tuxchick Sep 22, 2009 9:52 AM EDT |
What I think would be cool is an easier way to manage modules, and not by default end up with every video and networking interface driver in the world. I seem to recall the PCLinuxOS has an installation option to strip all the video drivers you don't need. |
| montezuma Sep 22, 2009 9:59 AM EDT |
Yes that would be great. The qt interface at present is just a prettyfication of the usual text or ncurses interfaces along with a whole bunch of way too technical comments about what each option means. I guess the kernel developers leave this sort of thing to the distributors and distributors are just interested in assembling a blackbox kernel that meets most users demands for hardware and stability. |
| bigg Sep 22, 2009 10:38 AM EDT |
The problem is that Linux has too much hardware support. What we need is a "Windows mode", where Linux only supports hardware that is supported by Windows. That would probably solve most of the problems with bloat. |
| jacog Sep 22, 2009 10:38 AM EDT |
I tink Mandriva also has a post-install option that removes all the unneeded drivers. I left them in though because I was a little uncertain what it would do when I plonk a USB device in there that was not detected at the time of install. |
| Steven_Rosenber Sep 22, 2009 11:38 AM EDT |
I wonder what we're talking about exactly. Just how big is this "kernel," anyway. Maybe it's trivial when taken in context. I do agree that an easy way to manage modules in a given installation's kernel is something that should be available (and probably is; I just don't know about it) |
| Bob_Robertson Sep 22, 2009 12:04 PM EDT |
> I seem to recall the PCLinuxOS has an installation option to strip all the video drivers you don't need. Debian has meta-packages for "xorg-input-all" and "xorg-video-all", and then Xorg autodetects (or finds in the xorg.conf) which specific one to use. All it takes is disk space, and a considerate user can go back in and remove the unused drivers once he knows which one is in use. If PCLinuxOS's install checks first and then only installs the working driver, that would cut down on work. That's one good side-effect of installing from a LiveCD rather than a generic install disk. For optimization of a working system, this is what I would like: 0) A tool that parses the loaded kernel modules and unloads what is not in use. While it would do little or nothing other than free up memory, I think it would be a public relations coup. 1) Automagic configuration of the configuration file for building a kernel, selecting only what is presently in use to be compiled in, everything else as loadable modules (just in case, a minimal waste of disk space and compile time, and the whole reason for loadable modules in the first place). Then building and installing of the custom kernel. 2) Optimization of the initrd.img for said custom kernel, making the assumption that catastrophic hardware changes have not been made since last time. Or would the optimized build above make the use of an initrd.img unnecessary? 3) Versioning of the above custom build so that if hardware changes have been made (or the magical build doesn't work), the "generic" kernel build remains available to start the process again. Bigg, that would do pretty much what you're saying, cut the "supported hardware" to a minimum in the running kernel, while keeping module auto-loading "just in case". Like when plugging in a USB thumbdrive and needing FAT16 for the first time in years. The last time I compiled a kernel was 2003, v2.4.xx, and even then the number of hardware modules to go through was awful. I can only imagine what it would be like now, so I'm right there with Monti in being intimidated. What that must be like for someone who has never compiled a kernel before....ugh! Serious intimidation. |
| montezuma Sep 22, 2009 12:43 PM EDT |
Bob, It would be a nice project to do what you suggest and then use the Intel benchmark to verify speedups. If you then did it for two quite different versions of the kernel (2.6.28 versus 2.6.14 say) you could check whether the bloat was coming from the additional unneeded drivers or from Linus and team being less than optimal with the "base" kernel..... |
| Bob_Robertson Sep 22, 2009 12:46 PM EDT |
Well, the Phoronix comparisons (to my eye) show some variations, but I don't know how to isolate file system module speed-ups from core kernel functionality. |
| bigg Sep 22, 2009 1:10 PM EDT |
> Bigg, that would do pretty much what you're saying, cut the "supported hardware" to a minimum in the running kernel, while keeping module auto-loading "just in case". Like when plugging in a USB thumbdrive and needing FAT16 for the first time in years. What I have in mind is either (a) allowing the user to keep the installation CD around in case you install new hardware, or (b) automatically downloading available drivers, assuming you have a working internet connection. I do not recall that I've ever compiled a kernel. It sounds scary. I'd much rather install a smaller kernel and add to it on an old machine. |
| jdixon Sep 22, 2009 1:17 PM EDT |
> A tool that parses the loaded kernel modules and unloads what is not in use. My understanding was that a kernel module was only loaded if you had hardware which needed it. Of course, that ignores things like the alsa-oss compatibility module and such, which alsa also loads. |
| Bob_Robertson Sep 22, 2009 1:37 PM EDT |
> My understanding was that a kernel module was only loaded if you had hardware which needed it. Of course, that ignores things like the alsa-oss compatibility module and such, which alsa also loads. From my experience, it is also possible to load a dynamic module that is not actually being used, if you deliberately do it "modprobe modulename" and its been included in the compile as a loadable module. The alsa-oss and a LOT of other sound modules get loaded, true, just by turning sound on. I've enabled enough sound cards in the past by hand. More than enough. So maybe my list of optimizations is redundant. Good! More demonstration that the Linux kernel environment is doing better than the sheer size of the source code might suggest. |
| jezuch Sep 22, 2009 2:58 PM EDT |
Quoting:Automagic configuration of the configuration file for building a kernel This was added to Linux in August: make localmodconfig (See http://lwn.net/Articles/347713/) |
| azerthoth Sep 22, 2009 3:19 PM EDT |
It would be safer to say that the 'kitchen sink' kernels are indeed in need of a diet plan, then you have to add in the initrd,initramfs, or what have you on top of it. You plug it in and it works has a cost, and size/performance is that cost. What we really need is something that says, you only have this hardware and only need these controllers for your system, would you like to build an optimized kernel. I do it by hand, and with one exception without an initrd or variant. Nice, small, and fast. |
| Bob_Robertson Sep 22, 2009 3:50 PM EDT |
> This was added to Linux in August: Coolness! |
| montezuma Sep 22, 2009 5:36 PM EDT |
jezuch, That would help (a lot) with speeding up module compilation but I'm not sure it would make a lot of difference with the slowdown noted by the intel benchmarks. After all when all is complete you will still be loading the same set of modules it's just that the rest won't be around.... I guess you could unload all the "useless" ones using rmmod before execution but my suspicion is that the biggest problem is with the builtin (non-modules) part of the kernel. Edit: I notice Alan Cox links to Lxer. Maybe he (or someone like him) could comment instead of klutzes like myself who are speculating. ;-) |
| jdixon Sep 22, 2009 10:26 PM EDT |
> ...it is also possible to load a dynamic module that is not actually being used, if you deliberately do it "modprobe modulename" and its been included in the compile as a loadable module. Probably, but unless you expect the hardware to be present at least part of the time, why would you want to do that? On the other hand, a number of modules I've used in the past have checked for applicable hardware and wouldn't load unless they found it (mostly ethernet cards, from memory). |
| jezuch Sep 23, 2009 2:40 AM EDT |
Quoting:That would help (a lot) with speeding up module compilation but I'm not sure it would make a lot of difference with the slowdown noted by the intel benchmarks. I'd like to see those benchmarks. |
| Bob_Robertson Sep 23, 2009 3:37 AM EDT |
> why would you want to do that? Ah, you see, I _don't_ want to do that. But I can, and have, because of hunting for the right driver for something before the days of semi-reliable auto-detection. As Monte points out it's not just a problem of modules, but of which modules. So something that merely reads what modules are presently loaded can make the error of over-provisioning. I really did mean "presently in use" in wish-list item 1, and that would also include un-selecting those modules which are compiled in the pre-mixed kernel but are unused. I guess that's why it's called a "wish" list, it doesn't mean it's practical or workable. Great movie BTW, "Frequently Asked Questions About Time Travel". Highly recommended. |
| montezuma Sep 23, 2009 8:22 AM EDT |
>I'd like to see those benchmarks. I also. It's a bit hard saying anything definitive on this issue until you know those details. Relevancy is all in benchmarks. |
Posting in this forum is limited to members of the group: [ForumMods, SITEADMINS, MEMBERS.]
Becoming a member of LXer is easy and free. Join Us!