linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dave Jones <davej@redhat.com>
To: Pavel Machek <pavel@ucw.cz>
Cc: Chuck Ebbert <76306.1226@compuserve.com>,
	Andrew Morton <akpm@osdl.org>, Ashok Raj <ashok.raj@intel.com>,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [patch -mm4] i386: __init should be __cpuinit
Date: Thu, 2 Feb 2006 16:39:09 -0500	[thread overview]
Message-ID: <20060202213909.GH11831@redhat.com> (raw)
In-Reply-To: <20060202213450.GA2405@elf.ucw.cz>

On Thu, Feb 02, 2006 at 10:34:50PM +0100, Pavel Machek wrote:
 > Hi!
 > 
 > >  > When CONFIG_HOTPLUG_CPU on i386 there are places where __init[data] is
 > >  > referenced from normal code.
 > >  > 
 > >  > On startup:
 > >  >         arch/i386/kernel/cpu/amd.c::amd_init_cpu():
 > >  >                 cpu_devs[X86_VENDOR_AMD] = &amd_cpu_dev;        
 > >  >         amd_cpu_dev is declared __initdata and is freed
 > >  > 
 > >  > On CPU hotplug:
 > >  >         arch/i386/kernel/cpu/common.c::get_cpu_vendor():
 > >  >                for (i = 0; i < X86_VENDOR_NUM; i++) {
 > >  >                         if (cpu_devs[i]) {
 > >  >                                 if (!strcmp(v,cpu_devs[i]->c_ident[0]) ||
 > >  > 
 > >  > To fix this, change every instance of __init that seems suspicious
 > >  > into __cpuinit.  When !CONFIG_HOTPLUG_CPU there is no change in .text
 > >  > or .data size.  When enabled, .text += 3248 bytes; .data += 2148 bytes.
 > >  > 
 > >  > This should be safe in every case; the only drawback is the extra code and
 > >  > data when CPU hotplug is enabled.
 > > 
 > > Especially as for the bulk of them, those CPUs aren't hotplug capable.
 > > (I seriously doubt we'll ever see a hotplugable cyrix for eg, which
 > >  takes up the bulk of your diff).
 > > 
 > > How about leaving it __init on non-hotplug systems, and somehow removing
 > > those from cpu_devs, so get_cpu_vendor() just skips them ?
 > > NULL'ing those entries should be just a few bytes, instead of adding 5KB.
 > 
 > We use cpu hotplug system for swsusp; but unless someone makes
 > cyrix/SMP machine and tries to suspend it, we are ok.

As Alan mentioned, there were never any production SMP cyrix machines,
and the prototypes never worked on Linux anyway.  With Cyrix no longer
around this code is safe to assume 'UP only'.

		Dave

 


  reply	other threads:[~2006-02-02 21:41 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-01  4:49 [patch -mm4] i386: __init should be __cpuinit Chuck Ebbert
2006-02-01  5:33 ` Dave Jones
2006-02-01  8:05   ` Matthew Garrett
2006-02-01 16:03     ` Dave Jones
2006-02-01 18:56       ` Alan Cox
2006-02-01 19:15         ` Ashok Raj
2006-02-02 21:34   ` Pavel Machek
2006-02-02 21:39     ` Dave Jones [this message]
2006-02-01  8:03 Chuck Ebbert

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=20060202213909.GH11831@redhat.com \
    --to=davej@redhat.com \
    --cc=76306.1226@compuserve.com \
    --cc=akpm@osdl.org \
    --cc=ashok.raj@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pavel@ucw.cz \
    /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;
as well as URLs for NNTP newsgroup(s).