Re: [PATCH 407/493] infiniband: remove use of __devexit

[Greg KH <gregkh@linuxfoundation.org>]

On Mon, Nov 19, 2012 at 02:49:22PM -0700, Jason Gunthorpe wrote:
> On Mon, Nov 19, 2012 at 12:19:38PM -0800, Greg KH wrote:
> > On Mon, Nov 19, 2012 at 01:09:21PM -0700, Jason Gunthorpe wrote:
> > > On Mon, Nov 19, 2012 at 01:25:56PM -0500, Bill Pemberton wrote:
> > > > CONFIG_HOTPLUG is going away as an option so __devexit is no
> > > > longer needed.
> > > 
> > > I'm sad to hear this, it is an easy space saver on my non-modular
> > > emebedded systems :(
> > 
> > Really?  I asked for details, and it was reported that this only saved
> > 1-200 bytes or so.  See the lkml archives for the details of this.
> 
> I just checked for you:
> 
> Old 2.6.16 powerpc 32 kernel:
> 
>    text    data     bss     dec     hex filename
> 2399368  222224  156124 2777716  2a6274 build/vmlinux
> 2394634  221804  156124 2772562  2a4e52 build-nhp/vmlinux
> 
> That looks like around 5154 bytes to me
> 
> New 3.6 powerpc 32 kernel:
> 
>    text    data     bss     dec     hex filename
> 3352356  162812  218132 3733300  38f734 build/vmlinux
> 3347644  162648  217860 3728152  38e318 build-nhp/vmlinux
> 
> And that is about 5148 bytes.
> 
> In both cases the only difference is adding CONFIG_HOTPLUG=y to the
> config.
> 
> 5k isn't a lot, but in the context of 'I have to figure out how to
> trim ~1MB off the 3.6 kernel to run it in our smallest hardware' it is
> the wrong direction :(

It is only 0.138% in the "wrong" direction.  Seriously, that's a very
tiny percentage here, for an option that people _always_ get wrong, and
almost no system does not need.  The number of bugs we have had in this
area is huge, and by fixing this option like this, it takes them all
away.

Yes, there are going to be exceptions, like yours, that somehow do run
properly without CONFIG_HOTPLUG enabled.  But really, are you worried
about 0.138% right now?  The amount of time we just spent writing these
emails, memory sizes increased this much for your next platform, for the
same cost as your last platform.

Also, as you point out above, it's a constant number that this option is
affecting, which is good for you, because as time goes on, it's a
smaller and smaller percentage of the overall space used by your kernel.

Thanks for running the numbers, I appreciate it.  I'm amazed that your
kernel growth from 2.6.16 to 3.6 is 1Mb.  Why would you want to run the
3.6 kernel in a system designed for the 2.6.16 kernel (i.e. one designed
over 6 _years_ ago)?

A lot happens in 6 years :)

thanks,

greg k-h