Re: [block IO crash] Re: 2.6.39-rc5-git2 boot crashs

[Thomas Gleixner <tglx@linutronix.de>]

On Thu, 5 May 2011, werner wrote:
> 90% of the config options, users don't know for what they are.  Instead of
> more and more new config features in, EVERY CONFIG PARAMETER WHAT THE KERNEL
> CAN DETECT AT RUN TIME (at the beginning of booting) SHOULD BE THROWED OUT.
> And the kernel should be compiled 'everythingyes' as default.   Even then,
> with all exotic (but nowadays happening) boot-necessary input/output hardware
> included, my vmlinuz is only 10 MB big.   Sufficient memory for run this
> (together with an initrd for an installer) nowadays should exist on almost all
> computers.  All other, not-boot necessary modules are perhaps 50 MB, and since
> the Atari time with 20 MB harddisks passed, there is NO REASON FOR COMPILE
> SMALL THE KERNEL. Even on Android phones, compiling the kernel / modules 50 MB
> big but using often only a part, dont hurt. But for emergency, instead of
> completely configless, one could let 2 options for the kernel config:  normal,
> small (below 16 M memory).   Provisorically, one could but one should not
> include such a raw-selection menu in the kernel config, because to check and
> maintain the dependences of their various single config parameters would be
> big extra work.   Instead of this, one should rigorously make more and more
> config parameters definitively obsolete and reduce them by improving the
> corresponding runtime ability of the kernel.

Have a look outside of the x86 and "smartphone brag with your GBs of
RAM" world and you'll see that there are 

  - systems which really care about size reductions which are measured
    in kilobytes.

  - systems where runtime detection is impossible

  - systems where runtime detection is complete overkill in various
    aspects: boottime, memory footprint ...  

And you CANNOT put those requirements under a single CONFIG_VERY_SMALL=y
fits it all thing simply because embedded devices have those fundamental
different requirements vs. drivers, filesystems ....

Aside of that config options are a pretty useful mechanism to debug
problems.

And in the context of that particular case you are barking up the
completely wrong tree. The facts that

 - slub used the wrong macro

 - the CONFIG dependent x86 implementation of that this_cpu_* mess was
   crap to begin with

are not an argument at all to go and impose a 100MB/50MB/16MB or
whatever arbitrary choice you make limit of CONFIG_FITS_IT_ALL_*
approach.

That simply does not work.

Thanks,

	tglx