-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greg KH wrote:

On Sat, Sep 05, 2009 at 05:18:46PM +0200, Jan Engelhardt wrote:

...

Hi,

this seemingly illogical choice in Kernel:/HEAD/kernel-source-rt.src.rpm's config/*/* is puzzling, or just wrong.

$ diff -dpru config/i386/{default,pae} (some happens on config/{i386,x86_64}/default) -CONFIG_X86_MSR=m -CONFIG_X86_CPUID=m +CONFIG_X86_MSR=y +CONFIG_X86_CPUID=y -CONFIG_IPV6=m +CONFIG_IPV6=y -CONFIG_LIB80211=m +CONFIG_LIB80211=y -CONFIG_ATA=m +CONFIG_ATA=y

Just what is the purpose of doing that for the PAE/x64 config? It's like all but the i386-default config is horked.

Looks like someone copied the changes I made to the MOBLIN_20 branch to get boot speeds down :)

Greg, I this is true in the master branch too. I don't think you applied the Moblin config changes to i386-default - just pae. -desktop has the changes because I branched it from -pae. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkqiiMsACgkQLPWxlyuTD7L/dACfR6tAAWpMd132bfWXmzhiyaJp DWEAniHqDsNKM4rwywqKHfSsp0lknGdK =YqnG -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org

On Sat, Sep 05, 2009 at 11:50:35AM -0400, Jeff Mahoney wrote:

Greg KH wrote:

...

On Sat, Sep 05, 2009 at 05:18:46PM +0200, Jan Engelhardt wrote:

...

Hi,

this seemingly illogical choice in Kernel:/HEAD/kernel-source-rt.src.rpm's config/*/* is puzzling, or just wrong.

$ diff -dpru config/i386/{default,pae} (some happens on config/{i386,x86_64}/default) -CONFIG_X86_MSR=m -CONFIG_X86_CPUID=m +CONFIG_X86_MSR=y +CONFIG_X86_CPUID=y -CONFIG_IPV6=m +CONFIG_IPV6=y -CONFIG_LIB80211=m +CONFIG_LIB80211=y -CONFIG_ATA=m +CONFIG_ATA=y

Just what is the purpose of doing that for the PAE/x64 config? It's like all but the i386-default config is horked.

Looks like someone copied the changes I made to the MOBLIN_20 branch to get boot speeds down :)

Greg, I this is true in the master branch too. I don't think you applied the Moblin config changes to i386-default - just pae. -desktop has the changes because I branched it from -pae.

Yes, this is true, but the original question was referring to the -rt kernels, which I did not touch. Anyway, what's the problem of having these drivers built into the kernel and not a module? thanks, greg k-h -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org

On Sat, Sep 05, 2009 at 09:59:34PM +0200, Jan Engelhardt wrote:

On Saturday 2009-09-05 21:51, Greg KH wrote:

...

Yes, this is true, but the original question was referring to the -rt kernels, which I did not touch.

Anyway, what's the problem of having these drivers built into the kernel and not a module?

That your kernel grows when doing that, and ipv6 itself already contributes like 230K. scsi_mod another 140K, just to name two. Even if you end up using them, it seems fancier having them as modules :)

But it's slower to boot. And 99% of all systems that we ship load both of those modules. 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.

[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? thanks, greg k-h -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org

On Sun, Sep 06, 2009 at 12:26:32AM +0200, Jan Engelhardt wrote:

On Saturday 2009-09-05 23:32, Greg KH wrote:

...

On Sat, Sep 05, 2009 at 09:59:34PM +0200, Jan Engelhardt wrote:

...

On Saturday 2009-09-05 21:51, Greg KH wrote:

...

Yes, this is true, but the original question was referring to the -rt kernels, which I did not touch.

Anyway, what's the problem of having these drivers built into the kernel and not a module?

That your kernel grows when doing that, and ipv6 itself already contributes like 230K. scsi_mod another 140K, just to name two. Even if you end up using them, it seems fancier having them as modules

But it's slower to boot. And 99% of all systems that we ship load both of those modules.

Yes, for _these two_ I would agree. But the other "99%" of options changed - I do not. Basically because there are far fewer than 99% running all that specific hardware at the same time.

* CONFIG_ATA_PIIX, CONFIG_SATA_AHCI - tho my chip is PATA_SIS, or PATA_ALI/PATA_VIA, whichever comes around

AHCI is much more popular.

* CONFIG_HID - tho periph is PS2 keyboard/mouse

Majority of systems have a USB keyboard or mouse.

* CONFIG_HWMON, CONFIG_I2C - for one desktop I always get bogus values with sensors(8), so I am counting it towards "not using hwmon/i2c"

Other drivers needed it.

* CONFIG_LEDS_CLASS - have not seen this on x86 at all

Then you haven't been paying attention :)

* CONFIG_LIB80211 - wireless is done by a dedicated device

But wireless drivers need it.

* CONFIG_RTC_CLASS - only seen this on x86; and I wonder if anything on a desktop besides mplayer & co, and hwclock(8) uses the rtc.

Yes, your boot scripts need it, so it is _much_ faster to have it in the kernel, you can save a few _seconds_ by putting it in the kernel.

* CONFIG_SOUND - well I dunno, I commonly keep servers without sound.

Then you will not mind it being there :)

* CONFIG_USB_[EOU]HCI_HCD - I am guaranteed to not have at least one of those HCIs.

True, so how do I know ahead of time which one it is?

* CONFIG_USB_STORAGE - also something I may not be using

But the majority of the world is.

* CONFIG_X86_MSR, CONFIG_X86_CPUID - never ever used. Never seen it in lsmod, hence there seem to be no programs using it.

Your boot sequence needs it.

All reasons for me to not have them =y at all times.

...

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 the way kernel code works. It can throw away code sections that it knows it is not going to need after startup. For the same code as a module, it does not.

...

...

[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.

What do you mean by this? We need to build these things in if we want a fast boot sequence. Right now, with these options, we are running sub-1-second boot out of the kernel to init. A full init sequence from power on is taking 2-3 seconds right now. So stuff like this is necessary if you want fast booting on your machine. If you have some numbers as to exactly how much memory this is "wasting" and can show us how to get the speed back, I would love to hear it. thanks, greg k-h -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jan Engelhardt wrote:

On Saturday 2009-09-05 23:32, Greg KH wrote:

...

On Sat, Sep 05, 2009 at 09:59:34PM +0200, Jan Engelhardt wrote:

...

On Saturday 2009-09-05 21:51, Greg KH wrote:

...

Yes, this is true, but the original question was referring to the -rt kernels, which I did not touch.

Anyway, what's the problem of having these drivers built into the kernel and not a module? That your kernel grows when doing that, and ipv6 itself already contributes like 230K. scsi_mod another 140K, just to name two. Even if you end up using them, it seems fancier having them as modules But it's slower to boot. And 99% of all systems that we ship load both of those modules.

Yes, for _these two_ I would agree. But the other "99%" of options changed - I do not. Basically because there are far fewer than 99% running all that specific hardware at the same time.

* CONFIG_ATA_PIIX, CONFIG_SATA_AHCI - tho my chip is PATA_SIS, or PATA_ALI/PATA_VIA, whichever comes around

* CONFIG_HID - tho periph is PS2 keyboard/mouse

* CONFIG_HWMON, CONFIG_I2C - for one desktop I always get bogus values with sensors(8), so I am counting it towards "not using hwmon/i2c"

* CONFIG_LEDS_CLASS - have not seen this on x86 at all

* CONFIG_LIB80211 - wireless is done by a dedicated device

* CONFIG_RTC_CLASS - only seen this on x86; and I wonder if anything on a desktop besides mplayer & co, and hwclock(8) uses the rtc.

* CONFIG_SOUND - well I dunno, I commonly keep servers without sound.

* CONFIG_USB_[EOU]HCI_HCD - I am guaranteed to not have at least one of those HCIs.

* CONFIG_USB_STORAGE - also something I may not be using

* CONFIG_X86_MSR, CONFIG_X86_CPUID - never ever used. Never seen it in lsmod, hence there seem to be no programs using it.

All reasons for me to not have them =y at all times.

...

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.

...

...

[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. 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. 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. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkqkah4ACgkQLPWxlyuTD7JyuACeMdJNBVSD6F1wFoEouhyawahA HIwAn2i6BZARhMzSAN7pLd3DIRvzP0IY =lGTj -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org

-----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].

[1] http://markmail.org/message/mpn7dc5cdr5ao7u7

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

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greg KH wrote:

On Sat, Sep 05, 2009 at 11:50:35AM -0400, Jeff Mahoney wrote:

...

...

On Sat, Sep 05, 2009 at 05:18:46PM +0200, Jan Engelhardt wrote:

...

Hi,

this seemingly illogical choice in Kernel:/HEAD/kernel-source-rt.src.rpm's config/*/* is puzzling, or just wrong.

$ diff -dpru config/i386/{default,pae} (some happens on config/{i386,x86_64}/default) -CONFIG_X86_MSR=m -CONFIG_X86_CPUID=m +CONFIG_X86_MSR=y +CONFIG_X86_CPUID=y -CONFIG_IPV6=m +CONFIG_IPV6=y -CONFIG_LIB80211=m +CONFIG_LIB80211=y -CONFIG_ATA=m +CONFIG_ATA=y

Just what is the purpose of doing that for the PAE/x64 config? It's like all but the i386-default config is horked. Looks like someone copied the changes I made to the MOBLIN_20 branch to get boot speeds down :) Greg, I this is true in the master branch too. I don't think you applied

Greg KH wrote: the Moblin config changes to i386-default - just pae. -desktop has the changes because I branched it from -pae.

Yes, this is true, but the original question was referring to the -rt kernels, which I did not touch.

Anyway, what's the problem of having these drivers built into the kernel and not a module?

I don't have any objections beyond the usual ones. I just want the configs to be identical outside of the stated differences. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkqkaCYACgkQLPWxlyuTD7KfBQCgjjhHJ0CE523kIwtkHiQIBeP4 D+oAoIQOhT4oYWfVPZvvi23yHLpxNaUb =Uvdt -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andreas Jaeger wrote:

Reading the discussion, Jan mentioned "I don't have sound on my server". AFAIK we have the -pae and the -desktop kernels on i586. The -pae is the server kernel - the -desktop is the one that we want for fast booting etc.

Do we have documented in the wiki or the kernel-source package the kernel flavours and what differences they should have?

That's a really good point. I branched the desktop kernel after Greg did the Moblin changes. We can probably back off a few of the Moblin configuration things on the pae flavor now. I'll take a look this week. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkqlVH0ACgkQLPWxlyuTD7J4CgCeJmyow4URBQkXrtglm0+dS2FH VRgAnjhtTTMWVgz5ioyXbixsGVACfHbE =qYB/ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org