public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Matt Mackall <mpm@selenic.com>
Cc: Jiri Kosina <jkosina@suse.cz>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	David Woodhouse <dwmw2@infradead.org>,
	Ingo Molnar <mingo@redhat.com>
Subject: Re: Bloatwatch 2.6.28-rc1: i8042 DMI lookup tables
Date: Fri, 24 Oct 2008 20:46:02 -0400	[thread overview]
Message-ID: <200810242046.02743.dmitry.torokhov@gmail.com> (raw)
In-Reply-To: <1224890002.3248.71.camel@calx>

On Friday 24 October 2008, 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?
> 

I think that the net effect of this change is positive. While it is
true that the size of the kernel image grew we do discard more memory
(most of DMI tables are marked __initdata) than we were able to do
before DMI strings were embedded into dmi_strmatch so the footprint of
the running kernel now should be smaller. Having said this I wonder if
we could reduce the length of these strings form 79 to let's say 39. 

I would like to get rid of .ident strings in cases when drivers don't
use them for anything, this should free some more memory.

-- 
Dmitry

  reply	other threads:[~2008-10-25  0:46 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-24 20:25 Bloatwatch 2.6.28-rc1: i8042 DMI lookup tables Matt Mackall
2008-10-24 22:15 ` Jiri Kosina
2008-10-24 23:13   ` Matt Mackall
2008-10-25  0:46     ` Dmitry Torokhov [this message]
2008-10-25  3:31       ` Matt Mackall
2008-10-25  8:20         ` David Woodhouse
2008-10-26  0:28       ` Jiri Kosina
2008-10-25  8:14     ` David Woodhouse

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200810242046.02743.dmitry.torokhov@gmail.com \
    --to=dmitry.torokhov@gmail.com \
    --cc=dwmw2@infradead.org \
    --cc=jkosina@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=mpm@selenic.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox