Optimized kernel builds: the straight dope

[Quim Calpe]

I fully agree with this approach, I think it's a win-win scenario:
- For developers, having to maintain only 2 (ideally only one if the
legacy drivers are sorted out)
- Saving bandwidth and space
- For users, simplicity is always good, not having to worry about what
kernel is appropriate for his computers it's a big step forward IMHO.

Even with bigger and real differences in benchmarks, the point is still
valid.
I'm a AMD XP 2200+ user, and -k7 kernels only throw me with ACPI
problems and non noticeable gains in speed, so I'm using already the
i386 kernel...

Quim 

 

On Mon, 2006-08-14 at 21:32 -0700, Matt Zimmerman wrote:
> On Mon, Aug 14, 2006 at 09:50:38PM -0500, Scott White wrote:
> > Regardless this makes sense to me and I'm in favor of it.  Having run Ubuntu
> > on several different architectures, Intel 686, Intel SMP + AMD64, I can't
> > say I've seen any obvious difference.  My only question is that it doesn't
> > seem that benchmarks were done in applications that wouldn't leverage many
> > instructions opened up in recent architectures or applications (such as
> > multimedia) or that are SMP driven such as MySql or high-end graphics work
> > (even games).
> 
> The use of newer instruction sets by applications is irrelevant to this
> test; you can still run i686 instructions regardless of which kernel you
> use.  We are only measuring the impact of building the kernel differently,
> not applications.  I would very much like to see similar data for that, of
> course, but so far no one has taken up the challenge.
> 
> This test was also explicitly performed on uniprocessor systems.  There's a
> very good reason for this, which is that what we currently call the -386
> kernel can't support SMP because it contains some additional legacy drivers
> which don't work with an SMP kernel.  It wouldn't be fair to compare these
> kernels on a multiprocessor system.
> 
> So in addition, this test shows that there is no slowdown by using our
> SMP-enabled kernel on uniprocessor systems, which is also great news.  This
> means that in Edgy, we will support multiprocessor and dual-core desktop
> systems out of the box, with no download and no performance penalty.  The
> uniprocessor-only kernel with the legacy drivers will still be available on
> the alternate CD.
> 
> So in a nutshell, we should be able to ship at most two variants of the
> desktop i386 kernel, one omitting a few drivers (the default) and one for
> uniprocessor only with all drivers (the alternate).  This is a big win both
> for kernel maintenance and for end user simplicity; users will only seek out
> the alternate kernel if they need it.
> 
> If we can resolve the SMP issues with those few drivers, then we can ship a
> single optimal kernel for everyone, which will be even better still.  Ben is
> collecting a list of the SMP-unfriendly drivers now.
> 
> -- 
>  - mdz
>