On Monday 2009-09-07 04:04, Jeff Mahoney wrote:
And, by building them into the kernel, you actually save a bit of space, as the kernel can throw away the __init section, which it does not for kernel modules.
Why is that, what requires __init sections of modules?
It's actually the __exit sections that get dropped, since a statically linked driver can't be unloaded.
Yes, _that_ makes sense. But the large part, I would claim, is __init functions and data, and __exit should be much smaller, because you do not need static device id tables to unload a module. __exit functions also tend to be simpler because you do not need error checking everywhere.
[N.B. Over the past year, the amount of modules loaded in a Linux system rose near the number of the modules loaded in a Solaris 11beta system.] Does it actually affect overall performace and is it faster than the increase in processor power and memory sizes?
I dunno, I just used it for a specific development task some year ago.
I've heard reports that a modular kernel wastes some memory because of some page alignment issues, but that seems like a trivially small amount of memory compared to the size of main memory. The other thing was the use of indirect calls, but I don't really buy that argument either.
If you look at lsmod you will see that all modules are loaded at PAGE_SIZE-divisble addresses. This seems inherent in mmap(2) requiring page-aligned addresses. 83 modules totalling 3440K (per lsmod) "waste" 160K of alignment here (4K pagesize).
I share your opinion of wanting a modular kernel, but not your reasons. The drivers that are now statically linked are common enough to be on a significant majority of systems, waste little enough memory so as not to be a real concern, and are proven to decrease kernel initialization time substantially. If there was a one-size-fits-all image then we wouldn't need a modular kernel at all. Unfortunately, when we're targetting a fast boot time and don't have another solution, we're left with the static driver approach.
Similar to mkinitrd, there could be an mkkernel (though it's a little utopic I agree) that takes a preshipped compiled kernel source and only does the link stage (which should complete rather quick compared to a full compile).
I had been working on a "megamodule" implementation where the modules are linked against each other and then loaded as a blob without an initrd, but I haven't had time to persue it.
From memory savings standpoint, it is very well worth it. Even with an initrd, because the .ko overhead is significant. I did something similar for all the smallish Netfilter/Xtables modules and saved quite a lot [1].
[1] http://markmail.org/message/mpn7dc5cdr5ao7u7 .oO(Now I got to figure out why things just grew between .29 and .31, even though having Greg's modules changed back to =m for the time.. -rw-r--r-- 1 root root 1768832 Aug 17 22:12 vmlinuz-2.6.29.6-rt -rw-r--r-- 1 root root 2275264 Sep 6 18:46 vmlinuz-2.6.31-rc8-rt) -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org