On Thu, Oct 14, 2004 at 01:57:50PM -0400, Richard B. Johnson wrote:
>
> Attached. This difference in size might make one think that
> there's more in the 2.6.8 basic compile, but most stuff is
> strings that say "BLAW is not set", which us longer than
> "BLAW=y" or "BLAW=m". In fact, about twice as long....
A cursory examination show that the two aren't even remotely
similar in a lot of cases. Take the misc filesystems section
for example.. (edited for brevity)
2.4
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
CONFIG_EFS_FS=m
CONFIG_HPFS_FS=m
CONFIG_SYSV_FS=m
CONFIG_UFS_FS=m
2.6
# Miscellaneous filesystems
#
CONFIG_AFFS_FS=m
CONFIG_HFS_FS=m
CONFIG_HFSPLUS_FS=m
CONFIG_BEFS_FS=m
CONFIG_BFS_FS=m
CONFIG_EFS_FS=m
CONFIG_JFFS2_FS=m
CONFIG_JFFS2_FS_NAND=y
CONFIG_JFFS2_ZLIB=y
CONFIG_JFFS2_RTIME=y
CONFIG_CRAMFS=m
CONFIG_VXFS_FS=m
CONFIG_QNX4FS_FS=m
CONFIG_SYSV_FS=m
CONFIG_UFS_FS=m
And you wonder why 2.6 is taking longer ?
There are many more cases like this in your configs..
Unless you're comparing apples to apples, this is
just nonsense.
Dave
On Thu, 14 Oct 2004, Dave Jones wrote:
> On Thu, Oct 14, 2004 at 01:57:50PM -0400, Richard B. Johnson wrote:
> >
> > Attached. This difference in size might make one think that
> > there's more in the 2.6.8 basic compile, but most stuff is
> > strings that say "BLAW is not set", which us longer than
> > "BLAW=y" or "BLAW=m". In fact, about twice as long....
>
> A cursory examination show that the two aren't even remotely
> similar in a lot of cases. Take the misc filesystems section
> for example.. (edited for brevity)
>
> 2.4
> # Miscellaneous filesystems
> #
> # CONFIG_ADFS_FS is not set
> # CONFIG_AFFS_FS is not set
> # CONFIG_HFS_FS is not set
> # CONFIG_HFSPLUS_FS is not set
> # CONFIG_BEFS_FS is not set
> # CONFIG_BFS_FS is not set
> CONFIG_EFS_FS=m
> CONFIG_HPFS_FS=m
> CONFIG_SYSV_FS=m
> CONFIG_UFS_FS=m
>
> 2.6
>
> # Miscellaneous filesystems
> #
> CONFIG_AFFS_FS=m
> CONFIG_HFS_FS=m
> CONFIG_HFSPLUS_FS=m
> CONFIG_BEFS_FS=m
> CONFIG_BFS_FS=m
> CONFIG_EFS_FS=m
> CONFIG_JFFS2_FS=m
> CONFIG_JFFS2_FS_NAND=y
> CONFIG_JFFS2_ZLIB=y
> CONFIG_JFFS2_RTIME=y
> CONFIG_CRAMFS=m
> CONFIG_VXFS_FS=m
> CONFIG_QNX4FS_FS=m
> CONFIG_SYSV_FS=m
> CONFIG_UFS_FS=m
>
> And you wonder why 2.6 is taking longer ?
> There are many more cases like this in your configs..
>
> Unless you're comparing apples to apples, this is
> just nonsense.
>
> Dave
>
No. I didn't time `make modules`, only `make bzImage`.
`make modules` takes too long to time (really) I don't
want to use any CPU resources which will screw up the
timing and I need to use the computer.
A wall-clock guess is that `make modules` takes about
an hour on the new system while it takes about 4 minutes
on the old. The new kernel build procedure is truly
horrible for the wall-clock time that is used.
For oranges vs oranges, if I compile Version 2.4.26
on a version 2.6.8 OS computer, the compile-time
is within tens of seconds. I'm not complaining about
the resulting kernel code performance, only the
abortion^M^M^M^M^M^Mjunk used to create a new kernel.
It 'make' won't do it, we have a problem and make
needs to be fixed.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.8 on an i686 machine (5537.79 BogoMips).
Note 96.31% of all statistics are fiction.
On Thu, 14 Oct 2004, Dave Jones wrote:
> On Thu, Oct 14, 2004 at 02:30:08PM -0400, Richard B. Johnson wrote:
>
> > No. I didn't time `make modules`, only `make bzImage`.
> > `make modules` takes too long to time (really) I don't
> > want to use any CPU resources which will screw up the
> > timing and I need to use the computer.
>
> You still have to calculate dependancies and such for
> anything built modular. Also a bunch of code built into
> the bzImage changes if things are built modular.
>
> the two comparisons aren't equal. Additionally,
> you haven't factored in the fact that 'make dep'
> is no longer needed. This accounts for a big chunk
> of time on 2.4 kernel builds.
>
> > A wall-clock guess is that `make modules` takes about
> > an hour on the new system while it takes about 4 minutes
> > on the old. The new kernel build procedure is truly
> > horrible for the wall-clock time that is used.
> >
> > For oranges vs oranges, if I compile Version 2.4.26
> > on a version 2.6.8 OS computer, the compile-time
> > is within tens of seconds. I'm not complaining about
> > the resulting kernel code performance, only the
> > abortion^M^M^M^M^M^Mjunk used to create a new kernel.
> > It 'make' won't do it, we have a problem and make
> > needs to be fixed.
>
> oranges to oranges means _exactly_ the same options
> (where they haven't changed from 2.4 -> 2.6) are
> set/unset. Anything else is totally bogus.
>
> If you find things are still taking phenomenally
> long times to build, then something is wrong somewhere.
> Don't you find it strange you're the only person
> to have complained about this ? If it was as big
> a problem as you're suggesting, those of us who
> do nothing but build kernels all day would be up in arms.
>
> Dave
>
I think you guys probably got used to it. Also, you
seldom build the whole thing, anymore, because the
dependencies are handled differently. I was used to
building stuff on 2.4.x. When I went to build stuff using
the new build procedure I was shocked. It was like the
old days with 66MHz '486s (fast) and 33MHz i386's. Of
course there weren't modules, then so 2hrs,30min
was normal. Now, with a CPU that's 80 times faster and
a front-side bus that's 12 time faster, and SCSI
disks that are 40 times faster, there just has to
be something wrong when a complete build of the kernel
takes an hour.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.8 on an i686 machine (5537.79 BogoMips).
Note 96.31% of all statistics are fiction.
On Thu, 14 Oct 2004, Richard B. Johnson wrote:
> On Thu, 14 Oct 2004, Dave Jones wrote:
> > If you find things are still taking phenomenally
> > long times to build, then something is wrong somewhere.
> > Don't you find it strange you're the only person
> > to have complained about this ? If it was as big
> > a problem as you're suggesting, those of us who
> > do nothing but build kernels all day would be up in arms.
>
> I think you guys probably got used to it. Also, you
> seldom build the whole thing, anymore, because the
> dependencies are handled differently. I was used to
> building stuff on 2.4.x. When I went to build stuff using
> the new build procedure I was shocked. It was like the
> old days with 66MHz '486s (fast) and 33MHz i386's. Of
> course there weren't modules, then so 2hrs,30min
> was normal. Now, with a CPU that's 80 times faster and
> a front-side bus that's 12 time faster, and SCSI
> disks that are 40 times faster, there just has to
> be something wrong when a complete build of the kernel
> takes an hour.
I have the impression 2.6 builds are more convenient, if not faster (sorry, no
hard data around due to ccache).
Perhaps you need to start using ccache (but that's true for building 2.4.x,
too)?
BTW, _if_ the build system got much slower, people who use ccache a lot would
notice, since the relative impact of the build system on the build time is
higher when using ccache.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Thu, Oct 14, 2004 at 03:03:51PM -0400, Richard B. Johnson wrote:
> I think you guys probably got used to it. Also, you
> seldom build the whole thing, anymore, because the
> dependencies are handled differently.
I build the whole thing, daily. from scratch, without
ccache, with something that isn't too far from a
make allmodconfig, on a half dozen different architectures
(with multiple builds for each sometimes - 586/686,
various ppc flavours etc).
Our build system spits out 2.6 kernel RPMs not noticably
slower their 2.4 counterparts, which were also pretty
close to a make allmodconfig.
If the builds took _twice_ as long, I would've been
shouting from the rooftops long ago.
The factors you mention make it sound like something is
very very wrong somewhere, but there's no clear sign why
this is affecting you so badly. Maybe you should try
profiling things and find out where the additional time
is being spent.
> building stuff on 2.4.x. When I went to build stuff using
> the new build procedure I was shocked. It was like the
> old days with 66MHz '486s (fast) and 33MHz i386's. Of
> course there weren't modules, then so 2hrs,30min
> was normal. Now, with a CPU that's 80 times faster and
> a front-side bus that's 12 time faster, and SCSI
> disks that are 40 times faster, there just has to
> be something wrong when a complete build of the kernel
> takes an hour.
How much RAM do you have ? And are you using the same
version of gcc for both 2.4 and 2.6 builds ?
Dave
On Thu, Oct 14, 2004 at 02:30:08PM -0400, Richard B. Johnson wrote:
> No. I didn't time `make modules`, only `make bzImage`.
> `make modules` takes too long to time (really) I don't
> want to use any CPU resources which will screw up the
> timing and I need to use the computer.
You still have to calculate dependancies and such for
anything built modular. Also a bunch of code built into
the bzImage changes if things are built modular.
the two comparisons aren't equal. Additionally,
you haven't factored in the fact that 'make dep'
is no longer needed. This accounts for a big chunk
of time on 2.4 kernel builds.
> A wall-clock guess is that `make modules` takes about
> an hour on the new system while it takes about 4 minutes
> on the old. The new kernel build procedure is truly
> horrible for the wall-clock time that is used.
>
> For oranges vs oranges, if I compile Version 2.4.26
> on a version 2.6.8 OS computer, the compile-time
> is within tens of seconds. I'm not complaining about
> the resulting kernel code performance, only the
> abortion^M^M^M^M^M^Mjunk used to create a new kernel.
> It 'make' won't do it, we have a problem and make
> needs to be fixed.
oranges to oranges means _exactly_ the same options
(where they haven't changed from 2.4 -> 2.6) are
set/unset. Anything else is totally bogus.
If you find things are still taking phenomenally
long times to build, then something is wrong somewhere.
Don't you find it strange you're the only person
to have complained about this ? If it was as big
a problem as you're suggesting, those of us who
do nothing but build kernels all day would be up in arms.
Dave