-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jan Engelhardt wrote:
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).
That's a ~4% overhead and still only wastes 40 pages.
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 did have an implementation that did this. The problem is that it makes all the -debuginfo packages worthless since the offsets don't match anymore. If there was a way to update the debuginfos, which there currently isn't, then it could be workable - except then you're left with a potentially different debuginfo for every installation. It wouldn't be enough to report your problem with a RPM version - you'd have to provide your debuginfo as well.
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].
Yeah, that is super messy. It would be cleaner to create a linker script that creates a new .init ELF section and then you can iterate over that with a helper function. That's essentially what my work does, except that I keep the separate init sections for modules. It increases disk space by a small amount but lets us keep the different module init "runlevels" that the *_initcall system provides. For reference, the disk space to memory space mapping isn't as close a relationship as your post implies. There are a bunch of sections that simply don't get loaded and others which are iterated over at module-load time and freed. I'm not disputing that there are memory savings here, just that it's enough to warrant all the effort to reclaim it. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkqlV9oACgkQLPWxlyuTD7LquACeJYV/FjTQDffm8Kxq0G4AKxyT niMAn19whKSZVT5R+pQLX3b1fWBswoGG =Ko4m -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org