Hello,
I have a machine here which I installed with Ubuntu 7.04. Immediately
after the installation had been finished, I installed the Ubuntu package
which contains the Ubuntu-modified sources of the linux kernel. I
extracted the resulting tar.bz2-file, copied the configuration of the
currently running kernel to .config and created a file localversion-irb
which contains the line "-irb" and then called "make menuconfig". In the
menu, I changed the CPU type from 586 to Pentium Pro and entered "-686"
as the localversion. Finally, I used the Ubuntu tool make-kpkg with
option "--initrd" to create a new kernel. The option "--initrd" causes
the installation scripts of the kernel package to automatically create
an initial ramdisk for the kernel.
After the new kernel package had been created, I installed it. After
that, I looked into the directory /boot and was very surprised: The
initial ramdisk of the new kernel was much larger than the initrd of the
old kernel. To find out the cause for this, I investigated how
directories /lib/modules/$old and /lib/modules/$new differ. I found out
that the filenames are the same, but the size of the files differs very
much. I found a module file in the new directory that was almost five
times as large as the file with the same name in the old directory.
So, my question is the follwing: Is it an expected feature that the file
sizes of modules grow so much only because of a different cpu type and a
different localversion, or is there probably a bug in my build tools?
Regards
Christoph
On 06/06/07, Christoph Pleger <[email protected]> wrote:
> Hello,
>
> I have a machine here which I installed with Ubuntu 7.04. Immediately
> after the installation had been finished, I installed the Ubuntu package
> which contains the Ubuntu-modified sources of the linux kernel. I
> extracted the resulting tar.bz2-file, copied the configuration of the
> currently running kernel to .config and created a file localversion-irb
> which contains the line "-irb" and then called "make menuconfig".
You forgot "make oldconfig". When you copy in a .config file from a
different kernel, always do oldconfig (just get in the habbit, if the
.config from the same kernel it's harmless).
> In the
> menu, I changed the CPU type from 586 to Pentium Pro and entered "-686"
> as the localversion. Finally, I used the Ubuntu tool make-kpkg with
> option "--initrd" to create a new kernel. The option "--initrd" causes
> the installation scripts of the kernel package to automatically create
> an initial ramdisk for the kernel.
>
> After the new kernel package had been created, I installed it. After
> that, I looked into the directory /boot and was very surprised: The
> initial ramdisk of the new kernel was much larger than the initrd of the
> old kernel. To find out the cause for this, I investigated how
> directories /lib/modules/$old and /lib/modules/$new differ. I found out
> that the filenames are the same, but the size of the files differs very
> much. I found a module file in the new directory that was almost five
> times as large as the file with the same name in the old directory.
>
> So, my question is the follwing: Is it an expected feature that the file
> sizes of modules grow so much only because of a different cpu type and a
> different localversion, or is there probably a bug in my build tools?
>
Compiling for a different CPU type will often change object file size,
but what you describe sounds extreme. I would have suspected something
along the lines of some debug options having been enabled - that would
more easily explain the large size difference.
--
Jesper Juhl <[email protected]>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
Christoph Pleger wrote:
> Hello,
>
[snip]
> After the new kernel package had been created, I installed it. After
> that, I looked into the directory /boot and was very surprised: The
> initial ramdisk of the new kernel was much larger than the initrd of the
> old kernel. To find out the cause for this, I investigated how
> directories /lib/modules/$old and /lib/modules/$new differ. I found out
> that the filenames are the same, but the size of the files differs very
> much. I found a module file in the new directory that was almost five
> times as large as the file with the same name in the old directory.
>
sounds more like you have debug options enabled?
-jb
--
Tact is the art of making a point without making an enemy.
On Jun 6 2007 17:51, Jesper Juhl wrote:
> On 06/06/07, Christoph Pleger <[email protected]> wrote:
>> Hello,
>>
>> I have a machine here which I installed with Ubuntu 7.04. Immediately
>> after the installation had been finished, I installed the Ubuntu package
>> which contains the Ubuntu-modified sources of the linux kernel. I
>> extracted the resulting tar.bz2-file, copied the configuration of the
>> currently running kernel to .config and created a file localversion-irb
>> which contains the line "-irb" and then called "make menuconfig".
>
> You forgot "make oldconfig". When you copy in a .config file from a
> different kernel, always do oldconfig (just get in the habbit, if the
> .config from the same kernel it's harmless).
oldconfig is automatically called AFAICS.
Jan
--
On Wed, Jun 06, 2007 at 05:05:34PM +0200, Christoph Pleger wrote:
> Hello,
>
> I have a machine here which I installed with Ubuntu 7.04. Immediately
> after the installation had been finished, I installed the Ubuntu package
> which contains the Ubuntu-modified sources of the linux kernel. I
> extracted the resulting tar.bz2-file, copied the configuration of the
> currently running kernel to .config and created a file localversion-irb
> which contains the line "-irb" and then called "make menuconfig". In the
> menu, I changed the CPU type from 586 to Pentium Pro and entered "-686"
> as the localversion. Finally, I used the Ubuntu tool make-kpkg with
> option "--initrd" to create a new kernel. The option "--initrd" causes
> the installation scripts of the kernel package to automatically create
> an initial ramdisk for the kernel.
>
> After the new kernel package had been created, I installed it. After
> that, I looked into the directory /boot and was very surprised: The
> initial ramdisk of the new kernel was much larger than the initrd of the
> old kernel. To find out the cause for this, I investigated how
> directories /lib/modules/$old and /lib/modules/$new differ. I found out
> that the filenames are the same, but the size of the files differs very
> much. I found a module file in the new directory that was almost five
> times as large as the file with the same name in the old directory.
>
> So, my question is the follwing: Is it an expected feature that the file
> sizes of modules grow so much only because of a different cpu type and a
> different localversion, or is there probably a bug in my build tools?
My best guess is that the orignally installed modules are stripped.
If you define INSTALL_MOD_STRIP then you would achieve the same.
>From Documentation/kbuild/makefile.txt:
INSTALL_MOD_STRIP
If this variable is specified, will cause modules to be stripped
after they are installed. If INSTALL_MOD_STRIP is '1', then the
default option --strip-debug will be used. Otherwise,
INSTALL_MOD_STRIP will used as the option(s) to the strip command.
So you could do something like this:
>$ INSTALL_MOD_STRIP=1 make modules_install
Sam
On Wed, Jun 06, 2007 at 05:51:24PM +0200, Jesper Juhl wrote:
> On 06/06/07, Christoph Pleger <[email protected]> wrote:
> >Hello,
> >
> >I have a machine here which I installed with Ubuntu 7.04. Immediately
> >after the installation had been finished, I installed the Ubuntu package
> >which contains the Ubuntu-modified sources of the linux kernel. I
> >extracted the resulting tar.bz2-file, copied the configuration of the
> >currently running kernel to .config and created a file localversion-irb
> >which contains the line "-irb" and then called "make menuconfig".
>
> You forgot "make oldconfig". When you copy in a .config file from a
> different kernel, always do oldconfig (just get in the habbit, if the
> .config from the same kernel it's harmless).
Christoph used menuconfig so his configuration was perfectly OK and
oldconfig would not have changed anything.
Sam
On Wed, Jun 06, 2007 at 05:05:34PM +0200, Christoph Pleger wrote:
> I found out that the filenames are the same, but the size of the files
> differs very much. I found a module file in the new directory that was
> almost five times as large as the file with the same name in the old
> directory.
For some reason I haven't looked into, copying the Ubuntu .config
file always results in having "Build the kernel with debug info"
set, which makes the resulting kernel huge. Ubuntu's distributed
kernel binary certainly doesn't have this stuff built in, so turn it
off in the "Kernel Hacking" menu.
If you find that your new kernel spews a lot of messages like "PM:
adding device nobus:yourmom", flip "Power Management Debugging" off
under the "Power management" menu also. I wouldn't do this
preemptively, though -- it turns off other stuff too, and I think
Ubuntu's kernel is patched not to do that (and newer kernels have the
options separated, I think).
Flipping the option and building a new package is pretty quick --
it doesn't rebuild much.
--
Joseph Fannin
[email protected] || [email protected]
On Wed, Jun 06, 2007 at 05:05:34PM +0200, Christoph Pleger wrote:
> So, my question is the follwing: Is it an expected feature that the file
> sizes of modules grow so much only because of a different cpu type and a
> different localversion, or is there probably a bug in my build tools?
>
The kernel is compiled with debug info so that we can strip it later to
build two packages, one with debugging information intact, and one
without it.
If you disable CONFIG_DEBUG_KERNEL, things should go back to normal
sizes for you.
Regards,
Kyle M.
On Thu, 7 Jun 2007, Kyle McMartin wrote:
> On Wed, Jun 06, 2007 at 05:05:34PM +0200, Christoph Pleger wrote:
> > So, my question is the follwing: Is it an expected feature that the file
> > sizes of modules grow so much only because of a different cpu type and a
> > different localversion, or is there probably a bug in my build tools?
>
> The kernel is compiled with debug info so that we can strip it later to
> build two packages, one with debugging information intact, and one
> without it.
>
> If you disable CONFIG_DEBUG_KERNEL, things should go back to normal
> sizes for you.
grow so much compared to *which other modules*? the ones that came
with your distro? if that's the case, try installing your new modules
with
# make INSTALL_MOD_STRIP=1 modules_install
that makes a *huge* difference in the size of the installed modules,
as i learned when i first ran across this on my fedora core system.
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================
On 06/08/2007 08:40 AM, Robert P. J. Day wrote:
>
> # make INSTALL_MOD_STRIP=1 modules_install
>
> that makes a *huge* difference in the size of the installed modules,
> as i learned when i first ran across this on my fedora core system.
>
learn how to use rpmbuild:
http://fedoraproject.org/wiki/Docs/CustomKernel
You can use --with/--without to build only what you want.
See the top of the specfile for details.
On Jun 8 2007 08:40, Robert P. J. Day wrote:
>>
>> If you disable CONFIG_DEBUG_KERNEL, things should go back to normal
>> sizes for you.
>
>grow so much compared to *which other modules*? the ones that came
>with your distro? if that's the case, try installing your new modules
>with
>
> # make INSTALL_MOD_STRIP=1 modules_install
>
>that makes a *huge* difference in the size of the installed modules,
>as i learned when i first ran across this on my fedora core system.
Definitely. Running depmod on debug-enabled .ko files explodes in a segfault
after depmod allocates more and more and more memory (exhausting both
my ram and swap).
Jan
--
On Sat, 2007-06-09 at 09:55 +0200, Jan Engelhardt wrote:
> On Jun 8 2007 08:40, Robert P. J. Day wrote:
> >>
> >> If you disable CONFIG_DEBUG_KERNEL, things should go back to normal
> >> sizes for you.
> >
> >grow so much compared to *which other modules*? the ones that came
> >with your distro? if that's the case, try installing your new modules
> >with
> >
> > # make INSTALL_MOD_STRIP=1 modules_install
> >
> >that makes a *huge* difference in the size of the installed modules,
> >as i learned when i first ran across this on my fedora core system.
>
> Definitely. Running depmod on debug-enabled .ko files explodes in a segfault
> after depmod allocates more and more and more memory (exhausting both
> my ram and swap).
So I missed half of this conversation - you're saying that on a
CONFIG_DEBUG_KERNEL, you have such large .ko module files that depmod
segfaults? Can I get a core dump or any further information? :-)
Jon.
On Jun 9 2007 08:08, Jon Masters wrote:
>
>So I missed half of this conversation - you're saying that on a
>CONFIG_DEBUG_KERNEL, you have such large .ko module files that depmod
>segfaults? Can I get a core dump or any further information? :-)
Just make sure your /lib/modules/<kernel> is like 300 megabytes or even
more. Then depmod will clog up quite a lot memory already. (Taking a 256 mb ram
machine for example, no swap or just very little.)
Jan
--
On Sat, 2007-06-09 at 15:59 +0200, Jan Engelhardt wrote:
> On Jun 9 2007 08:08, Jon Masters wrote:
> >
> >So I missed half of this conversation - you're saying that on a
> >CONFIG_DEBUG_KERNEL, you have such large .ko module files that depmod
> >segfaults? Can I get a core dump or any further information? :-)
>
> Just make sure your /lib/modules/<kernel> is like 300 megabytes or even
> more. Then depmod will clog up quite a lot memory already. (Taking a 256 mb ram
> machine for example, no swap or just very little.)
I'll go take a look at that.
Jon.
On 6/9/07, Jan Engelhardt <[email protected]> wrote:
>
> On Jun 9 2007 08:08, Jon Masters wrote:
> >
> >So I missed half of this conversation - you're saying that on a
> >CONFIG_DEBUG_KERNEL, you have such large .ko module files that depmod
> >segfaults? Can I get a core dump or any further information? :-)
>
> Just make sure your /lib/modules/<kernel> is like 300 megabytes or even
> more. Then depmod will clog up quite a lot memory already. (Taking a 256 mb ram
> machine for example, no swap or just very little.)
Yup, this would happen reproducibly on a machine with <= 256MB
RAM and swap disabled, when building a large enough modular kernel.
The depmod at end of modules_install would invariably invoke the OOM
killer, and get itself shot (taking down the shell with it, often) ...
Satyam
On Sat, 9 Jun 2007 15:59:55 +0200 (CEST) Jan Engelhardt wrote:
> On Jun 9 2007 08:08, Jon Masters wrote:
> >
> >So I missed half of this conversation - you're saying that on a
> >CONFIG_DEBUG_KERNEL, you have such large .ko module files that depmod
> >segfaults? Can I get a core dump or any further information? :-)
>
> Just make sure your /lib/modules/<kernel> is like 300 megabytes or
> even more. Then depmod will clog up quite a lot memory already.
> (Taking a 256 mb ram machine for example, no swap or just very
> little.)
I have noticed such problems before - the depmod code just loads whole
module files into memory. The situation is especially bad when
module-init-tools is configured with --enable-zlib - in this case memory
for all module files is allocated with malloc(). (Without --enable-zlib
depmod just mmaps all module files, which at least does not eat swap,
and probably does not bring unused pages into memory.)
I have made some patches to module-init-tools - unfortunately, they
probably don't apply to the current version (they were based on
v3.3-pre4):
git://git.altlinux.org/people/vsu/packages/module-init-tools.git
(release-module-data branch)
http://git.altlinux.org/people/vsu/packages/?p=module-init-tools.git;a=shortlog;h=release-module-data