From: "Jan Beulich" <JBeulich@suse.com>
To: "Petr Tesarik" <ptesarik@suse.cz>
Cc: "Borislav Petkov" <bp@alien8.de>, <x86@kernel.org>,
"Thomas Gleixner" <tglx@linutronix.de>,
"Ingo Molnar" <mingo@redhat.com>, <linux-kernel@vger.kernel.org>,
"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [PATCH] x86: Issue a warning if number of present CPUs > maxcpus and CONFIG_HOTPLUG=n
Date: Mon, 17 Feb 2014 08:34:34 +0000 [thread overview]
Message-ID: <5301D7AA020000780011CBE9@nat28.tlf.novell.com> (raw)
In-Reply-To: <20140215150223.63bb52fb@hananiah.suse.cz>
>>> On 15.02.14 at 15:02, Petr Tesarik <ptesarik@suse.cz> wrote:
> --- a/arch/x86/kernel/smpboot.c
> +++ b/arch/x86/kernel/smpboot.c
> @@ -1226,9 +1226,6 @@ __init void prefill_possible_map(void)
> #ifdef CONFIG_HOTPLUG_CPU
> if (setup_max_cpus)
> possible += disabled_cpus;
> -#else
> - if (possible > i)
> - possible = i;
> #endif
> } else
> possible = setup_possible_cpus;
In between here total_cpus is being set, which now will get a
larger value if !HOTPLUG_CPU. Did you check that this has no
unintended side effect? And even if you did, it would still feel
more safe if you moved that line down after the capping point
below.
Similarly (but perhaps less important, albeit possibly slightly
confusing) the NR_CPUS related warning could now get issued
along with the warning below (when possible > nr_cpu_ids > i).
Hence that may better be moved down too (or then in effect
the if() block you modify below would get moved up). I realize
that two warning instead of just one would also be possible
without any change, so you're not really introducing some
entirely new inconsistency here...
Jan
> @@ -1246,7 +1243,7 @@ __init void prefill_possible_map(void)
> if (!setup_max_cpus)
> #endif
> if (possible > i) {
> - pr_warn("%d Processors exceeds max_cpus limit of %u\n",
> + pr_warn("%d Processors exceeds maxcpus limit of %u\n",
> possible, setup_max_cpus);
> possible = i;
> }
> --
> 1.8.4.5
next prev parent reply other threads:[~2014-02-17 8:34 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-15 14:02 Petr Tesarik
2014-02-16 17:11 ` Borislav Petkov
2014-02-17 8:34 ` Jan Beulich [this message]
2014-02-17 10:04 ` Petr Tesarik
2014-02-17 13:40 ` Henrique de Moraes Holschuh
2014-02-17 14:16 ` Petr Tesarik
2014-02-17 19:07 ` Henrique de Moraes Holschuh
2014-02-17 19:31 ` Petr Tesarik
2014-02-17 22:51 ` Henrique de Moraes Holschuh
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=5301D7AA020000780011CBE9@nat28.tlf.novell.com \
--to=jbeulich@suse.com \
--cc=bp@alien8.de \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=ptesarik@suse.cz \
--cc=tglx@linutronix.de \
--cc=x86@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®