Re: Bloatwatch 2.6.28-rc1: i8042 DMI lookup tables

From: David Woodhouse <dwmw2@infradead.org>
To: Matt Mackall <mpm@selenic.com>
Cc: Jiri Kosina <jkosina@suse.cz>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	Ingo Molnar <mingo@redhat.com>
Subject: Re: Bloatwatch 2.6.28-rc1: i8042 DMI lookup tables
Date: Sat, 25 Oct 2008 09:14:52 +0100	[thread overview]
Message-ID: <1224922492.18031.12.camel@macbook.infradead.org> (raw)
In-Reply-To: <1224890002.3248.71.camel@calx>

On Fri, 2008-10-24 at 18:13 -0500, Matt Mackall wrote:
> On Sat, 2008-10-25 at 00:15 +0200, Jiri Kosina wrote:
> > On Fri, 24 Oct 2008, Matt Mackall wrote:
> > 
> > > We've added 12k of new initdata to allnoconfig builds for i8042 DMI
> > > lookup tables:
> > > 
> > > http://www.selenic.com/bloatwatch/?cmd=compare;v1=2.6.27;v2=2.6.28-rc1;part=/built-in/drivers
> > > 
> > > It looks like each table entry is > 320 bytes as we reserve four 80-byte
> > > slots in each for DMI match strings. 
> > 
> > Umm, and what is the actual problem with that, really?
> 
> The actual problem is that if the kernel grows by 12k every time a
> developer says "what's the big deal?" the kernel will become very large
> indeed.
> 
> > OK, we can remove it from .init, but then it will be rotting in memory 
> > forever, which is quite sub-optimal, when this kind of DMI information is 
> > needed only during initialization.
> 
> I wasn't complaining that they were in init, but rather that they were
> 12k. For something like 37 entries. The entry size is ridiculous and
> looks to have grown by a factor of 10 since 2.6.27. What, as they say,
> is up with that?
> 
> It looks like David Woodhouse is to blame:
> 
> commit d945b697d0eea5a811ec299c5f1a25889bb0242b
> Automatic MODULE_ALIAS() for DMI match tables.
> 
> This is probably also responsible for most of the growth in x86 I
> mentioned elsewhere, so it's about 25-30k damage in total. David?

There's an assessment of this in the commit comment which you omitted.

It compresses well, and it's __initdata. So it takes up very little
space in the bzImage, and is dropped fairly quickly during boot. So the
amount of time it's _actually_ taking up any noticeable amount of memory
is really quite small.

But if someone wants to extend modpost so that it can handle relocations
and we can use string _pointers_ in the dmi tables, that would be good.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation