From: Ashok Raj <ashok.raj@intel.com>
To: Andi Kleen <ak@muc.de>
Cc: Ashok Raj <ashok.raj@intel.com>, Andrew Morton <akpm@osdl.org>,
zwane@arm.linux.org.uk, linux-kernel@vger.kernel.org
Subject: Re: [patch 3/8] x86_64:Dont call enforce_max_cpus when hotplug is enabled
Date: Thu, 4 Aug 2005 09:28:41 -0700 [thread overview]
Message-ID: <20050804092841.A15274@unix-os.sc.intel.com> (raw)
In-Reply-To: <20050804104110.GB97893@muc.de>; from ak@muc.de on Thu, Aug 04, 2005 at 12:41:10PM +0200
On Thu, Aug 04, 2005 at 12:41:10PM +0200, Andi Kleen wrote:
> On Mon, Aug 01, 2005 at 01:20:20PM -0700, Ashok Raj wrote:
> > No need to enforce_max_cpus when hotplug code is enabled. This
> > nukes out cpu_present_map and cpu_possible_map making it impossible to add
> > new cpus in the system.
>
> Hmm - i think there was some reason for this early zeroing,
> but I cannot remember it right now.
>
> It might be related to some checks later that check max possible cpus.
>
> So it would be still good to have some way to limit max possible cpus.
> Maybe with a new option?
The only useful thing with enfore_max() is that cpu_possible_map is trimmed
so some resource allocations that use for_each_cpu() for upfront allocation
wont allocate resources.
Currently i see max_cpus only limiting boot-time start, none trim cpu_possible
which is done in only x86_64. max_cpu is still honored, just that for initial
boot. I would think maybe remove enforce_max_cpus() altogether like other
archs instead of adding one more just for x86_64.
Maybe we should add only if there is a need, instead of adding and finding
no-one using it and finally removing it very soon.
>
> -Andi
--
Cheers,
Ashok Raj
- Open Source Technology Center
next prev parent reply other threads:[~2005-08-04 16:30 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-08-01 20:20 [patch 0/8] Updated patches for x86_64 Ashok Raj
2005-08-01 20:20 ` [patch 1/8] x86_64: Reintroduce clustered_apic_check() " Ashok Raj
2005-08-01 22:36 ` Ashok Raj
2005-08-01 20:20 ` [patch 2/8] x86_64: create sysfs entries for cpu only for present cpus Ashok Raj
2005-08-04 10:37 ` Andi Kleen
2005-08-01 20:20 ` [patch 3/8] x86_64:Dont call enforce_max_cpus when hotplug is enabled Ashok Raj
2005-08-04 10:41 ` Andi Kleen
2005-08-04 16:28 ` Ashok Raj [this message]
2005-08-01 20:20 ` [patch 4/8] x86_64:Fix cluster mode send_IPI_allbutself to use get_cpu()/put_cpu() Ashok Raj
2005-08-04 10:43 ` Andi Kleen
2005-08-04 16:33 ` Ashok Raj
2005-08-01 20:20 ` [patch 5/8] x86_64:Dont do broadcast IPIs when hotplug is enabled in flat mode Ashok Raj
2005-08-04 10:51 ` Andi Kleen
2005-08-04 16:36 ` Ashok Raj
2005-08-04 17:27 ` Ashok Raj
2005-08-01 20:20 ` [patch 6/8] x86_64:Dont use Lowest Priority when using physical mode Ashok Raj
2005-08-01 20:20 ` [patch 7/8] x86_64:Use common functions in cluster and physflat mode Ashok Raj
2005-08-01 20:20 ` [patch 8/8] x86_64: Choose physflat for AMD systems only when >8 CPUS Ashok Raj
2005-08-04 10:54 ` Andi Kleen
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=20050804092841.A15274@unix-os.sc.intel.com \
--to=ashok.raj@intel.com \
--cc=ak@muc.de \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=zwane@arm.linux.org.uk \
/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