mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@osdl.org>
To: Ashok Raj <ashok.raj@intel.com>
Cc: ashok.raj@intel.com, olel@ans.pl, venkatesh.pallipadi@intel.com,
	linux-kernel@vger.kernel.org, suresh.b.siddha@intel.com,
	rajesh.shah@intel.com, ak@muc.de
Subject: Re: More than 8 CPUs detected and CONFIG_X86_PC cannot handle it on 2.6.16-rc6
Date: Mon, 13 Mar 2006 14:22:23 -0800	[thread overview]
Message-ID: <20060313142223.7ac20a65.akpm@osdl.org> (raw)
In-Reply-To: <20060313120552.A25020@unix-os.sc.intel.com>

Ashok Raj <ashok.raj@intel.com> wrote:
>
> 
> 
>  When CONFIG_HOTPLUG_CPU is turned on we always use physflat mode (bigsmp) even 
>  when #of CPUs are less than 8 to avoid sending IPI to offline processors.
> 
>  Without having BIGSMP on it spits out a warning during boot on systems that
>  seems misleading, since it complains even on systems that have less
>  than 8 cpus.
> 
>  Signed-off-by: Ashok Raj <ashok.raj@intel.com>
>  ---------------------------------------------------------
> 
>   arch/i386/Kconfig |    2 +-
>   1 files changed, 1 insertion(+), 1 deletion(-)
> 
>  Index: linux-2.6.16-rc6-mm1/arch/i386/Kconfig
>  ===================================================================
>  --- linux-2.6.16-rc6-mm1.orig/arch/i386/Kconfig
>  +++ linux-2.6.16-rc6-mm1/arch/i386/Kconfig
>  @@ -760,7 +760,7 @@ config PHYSICAL_START
>   
>   config HOTPLUG_CPU
>   	bool "Support for hot-pluggable CPUs (EXPERIMENTAL)"
>  -	depends on SMP && HOTPLUG && EXPERIMENTAL && !X86_VOYAGER
>  +	depends on SMP && HOTPLUG && EXPERIMENTAL && !X86_VOYAGER && !X86_PC
>   	---help---
>   	  Say Y here to experiment with turning CPUs off and on.  CPUs
>   	  can be controlled through /sys/devices/system/cpu.

Still seems wrong.  People _do_ use HOTPLUG_CPU on X86_PCs so they can get
software suspend.  The number of people who do this are probably 100000x
the number of people who have physically hotpluggable CPUs.  And I don't
think we can churn their config requirements this much so late in the game.

So for now I suggest we're best off simply killing the printk (or doing
something smarter, like comparing cpu_online-map with cpu_possible_map
(which isn't right)).

Longer term, it appears that we need to do some Kconfig and C work to
separate out the HOTPLUG_CPU infrastructure which swsusp needs from actual
CPU hotplugging.

What _is_ this IPI problem anyway?  Can't send point-to-point IPIs to
offlined CPUs?  (Don't do that then?) Or do broadcast IPIs go wrong, or
what?

And does it affect pretend-x86-hotplug, or is it only affecting real hotplug?

Thanks.

  reply	other threads:[~2006-03-13 22:25 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-12  2:04 Krzysztof Oledzki
2006-03-12  5:03 ` Andrew Morton
2006-03-12 11:04   ` Krzysztof Oledzki
2006-03-12 11:25     ` Andrew Morton
2006-03-12 13:05       ` Krzysztof Oledzki
2006-03-12 15:35         ` Venkatesh Pallipadi
2006-03-12 21:13           ` Krzysztof Oledzki
2006-03-12 22:30             ` Andrew Morton
2006-03-13 19:36               ` Ashok Raj
2006-03-13 19:51                 ` Andrew Morton
2006-03-13 20:05                   ` Ashok Raj
2006-03-13 22:22                     ` Andrew Morton [this message]
2006-03-13 23:04                       ` Ashok Raj
2006-03-15  5:44                         ` Nathan Lynch
2006-03-15  6:18                           ` Shaohua Li
2006-03-15  7:31                             ` Andrew Morton
2006-03-15  9:37                               ` [PATCH] No need to protect current->group_info in sys_getgroups(), in_group_p() and in_egroup_p() Eric Dumazet
2006-03-20 19:09                                 ` [PATCH] Use unsigned int types for a faster bsearch Eric Dumazet
2006-03-22  5:06                                   ` [PATCH] Use __read_mostly on some hot fs variables Eric Dumazet
2006-03-22  5:15                                     ` Nick Piggin
2006-03-22  6:23                                     ` [RFC, PATCH] avoid some atomics in open()/close() for monothreaded processes Eric Dumazet
2006-03-22  6:41                                       ` Andrew Morton
2006-03-22  6:59                                         ` Eric Dumazet
2006-03-22  7:03                                           ` Andrew Morton
2006-03-15 18:09                               ` More than 8 CPUs detected and CONFIG_X86_PC cannot handle it on 2.6.16-rc6 Ashok Raj
2006-03-15 10:50 Chuck Ebbert
2006-03-15 15:44 ` Krzysztof Oledzki

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=20060313142223.7ac20a65.akpm@osdl.org \
    --to=akpm@osdl.org \
    --cc=ak@muc.de \
    --cc=ashok.raj@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=olel@ans.pl \
    --cc=rajesh.shah@intel.com \
    --cc=suresh.b.siddha@intel.com \
    --cc=venkatesh.pallipadi@intel.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

Powered by JetHome