Optimized kernel builds: the straight dope [fp extensions]

[Matt Zimmerman]

On Tue, Aug 15, 2006 at 11:07:32PM +0200, Christian Leber wrote:
> On Tue, Aug 15, 2006 at 01:46:14PM -0700, Matt Zimmerman wrote:
> > > IMO getting rid of these optimized kernels should be done after much
> > > broader testing than 2 randomly chosen desktops. Think of people using
> > > encrypted filesystems, compressed filesystems, etc.
> > 
> > The case is already made for eliminating them, based on the maintenance
> > overhead, and there currently exists no evidence whatsoever in favour of
> > keeping them, though we have made some effort to collect it.  If you wish to
> > contribute your own measurements, you are welcome, but hypothetical
> > scenarios and arguments will not sway the decision.  This holds especially
> > true for niche use cases like the ones you name; we will not hesitate to
> > optimize for the common case at some small expense to scarce ones.
> 
> The only problem could come from functions like memcpy, fast_clear_page
> from /arch/i386/lib/mmx.c
> Benchmarking that in a complete system will be hard, i doubt that
> this functions are worth it, to keep more kernels and confusing people.
> 
> The cases of some hypothetical encrypted or compressed filesystems could be
> easily solved in a way like it is done for the RAID 5/6 modules. (they
> benchmark for the fastest algorithm every boot)

The routines you mention are not inlined, so there is no need to choose at
compile time which implementation to use.  It's a straightforward matter
to select the optimal routine at runtime, as you've seen in the case of the
RAID subsystem.  The generic optimizations already do this kind of thing.

-- 
 - mdz