All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sam Ravnborg <sam@ravnborg.org>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Arjan van de Ven <arjan@infradead.org>,
	torvalds@linux-foundation.org, linux-kernel@vger.kernel.org,
	Matt Mackall <mpm@selenic.com>
Subject: Re: [pull request] getting rid of __cpuinit
Date: Sat, 25 Oct 2008 23:36:38 +0200	[thread overview]
Message-ID: <20081025213638.GA27356@uranus.ravnborg.org> (raw)
In-Reply-To: <200810252020.01352.rjw@sisk.pl>

> > > I tried to look a the numbers of a defconfig build here.
> > > cpuinit.text equals 0x5d97 = 23959
> > > cpuinit.data equals 0x3574 = 13684
> > > 
> > > [objdump of vmlinux.o gives you the size of the cpuinit sections]
> > > 
> > > So if we decide to drop cpuinit then it should be based on the
> > > above figure and not the 2k figure you gave in the original mail.
> > > 
> > > Or even better we should see the difference with a typical
> > > embedded configuration and not some big defconfig build.
> > > I will assume the saving is less on a typical embedded
> > > configuration.
> > 
> > it will be; on x86 you end up inheriting all cpu vendors init code.
> > on embedded you only have  the dedicated CPU code.
> > 
> > ... just that on x86... nobody seems to be in this position, it's
> > almost impossble to have HOTPLUG_CPU even be asked.
> 
> FWIW, I like the idea of removing __cpuinit.  It often is quite difficult to
> determine if given piece of code should be marked as __cpuinit and that leads
> to bugs that are not so easy to resolve.

Getting rid of __cpuinit would be good - I do not questions this.
I only want the decision to be taken based on the correct numbers,
which Arjan failed to provide initially.

I decided to try to build a typical arm target - netwinder.
It had HOTPLUG disabled which is why I took this one.

objdump -h a/vmlinux.o | grep cpu
  4 .cpuinit.text 000006ac  00000000  00000000  0023e3e4  2**2
 41 .cpuinit.data 00000040  00000000  00000000  002c31a8  2**2

objdump -h a/vmlinux.o | grep text
  0 .text         00227b44  00000000  00000000  00000040  2**5
  1 .text.head    00000240  00000000  00000000  00227ba0  2**5
  2 .init.text    000150b0  00000000  00000000  00227de0  2**5
  4 .cpuinit.text 000006ac  00000000  00000000  0023e3e4  2**2
  7 .devinit.text 00005c24  00000000  00000000  0023f78c  2**2
  9 .exit.text    00001124  00000000  00000000  002453e4  2**2
 11 .meminit.text 000002d4  00000000  00000000  002482b0  2**2
 12 .devexit.text 00000348  00000000  00000000  00248584  2**2

So we see that for this config on arm we only save ~1700 bytes
by the cpuinit stuff. And for data we save even less.

__cpuinit is almost not used in arm specific code so what we
have here is the savings from the shared code.

Considering these numbers the gain/pain ratio is too low
and I agree that the cpuinit stuff should go.

The reports that removing cpuinit/exit stuff adds a new set
of warnings should just be looked at.
Except from the tricky __cpuinit cases it is almost always
trivial to fix when you have understood the problem.

	Sam

      reply	other threads:[~2008-10-25 21:37 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-24 21:20 [pull request] getting rid of __cpuinit Arjan van de Ven
2008-10-24 21:37 ` [PATCH] kbuild: drop cpuinit/cpuexit checks in modpost Sam Ravnborg
2008-10-25 23:56   ` Arjan van de Ven
2008-10-25  7:59 ` [pull request] getting rid of __cpuinit Sam Ravnborg
2008-10-25 14:00   ` Arjan van de Ven
2008-10-25 14:35     ` Sam Ravnborg
2008-10-25 15:06       ` Arjan van de Ven
2008-10-25 16:21         ` Sam Ravnborg
2008-10-25 16:29           ` Arjan van de Ven
2008-10-25 18:20             ` Rafael J. Wysocki
2008-10-25 21:36               ` Sam Ravnborg [this message]

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=20081025213638.GA27356@uranus.ravnborg.org \
    --to=sam@ravnborg.org \
    --cc=arjan@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mpm@selenic.com \
    --cc=rjw@sisk.pl \
    --cc=torvalds@linux-foundation.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.