From: Thomas Gleixner <tglx@linutronix.de>
To: Sudeep Holla <sudeep.holla@arm.com>,
Elliot Berman <eberman@codeaurora.org>
Cc: Qais Yousef <qais.yousef@arm.com>,
Peter Zijlstra <peterz@infradead.org>,
"Paul E. McKenney" <paulmck@kernel.org>,
Jonathan Corbet <corbet@lwn.net>,
Sudeep Holla <sudeep.holla@arm.com>,
Trilok Soni <tsoni@codeaurora.org>,
linux-kernel@vger.kernel.org, psodagud@codeaurora.org,
linux-doc@vger.kernel.org
Subject: Re: [PATCH] smp: Add bootcpus parameter to boot subset of CPUs
Date: Tue, 03 Nov 2020 23:10:06 +0100 [thread overview]
Message-ID: <871rha148x.fsf@nanos.tec.linutronix.de> (raw)
In-Reply-To: <20201030174531.ywwkcntq4ge33lrh@bogus>
On Fri, Oct 30 2020 at 17:45, Sudeep Holla wrote:
> On Thu, Oct 29, 2020 at 02:37:06PM -0700, Elliot Berman wrote:
>> In the case where commercial device is using feature for thermal, device
>> should boot multiple small cores. Booting only one core means we would not
>> be able to use all possible cores to maximum extent possible in this thermal
>> case.
>
> I understood that point. But you haven't responded on my logical vs physical
> number argument. I am clearly NACKing this patch as is for just usage of
> logical CPU IDs in the command line while your intention is to control
> the physical CPUs. So once again, NACK for that reason.
Correct. And no, we are not going to add a command line option to select
physical CPU ids.
There are two ways to solve that:
1) The firmware can tell the kernel whether a CPU should be brought up
or not, e.g. by failing the bootup request.
2) The kernel has a way to figure out the current thermal and/or power
budget early in the boot process and sorts out which and how many
CPUs fit into that limit.
Thanks,
tglx
next prev parent reply other threads:[~2020-11-03 22:10 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-22 22:04 [PATCH] smp: Add bootcpus parameter to boot subset of CPUs Elliot Berman
2020-10-23 7:45 ` Peter Zijlstra
2020-10-23 21:59 ` Thomas Gleixner
2020-10-26 17:08 ` psodagud
2020-10-26 17:12 ` Peter Zijlstra
2020-10-27 17:06 ` Elliot Berman
2020-10-28 14:55 ` Qais Yousef
2020-10-28 15:15 ` Sudeep Holla
2020-10-29 21:37 ` Elliot Berman
2020-10-30 17:45 ` Sudeep Holla
2020-11-03 22:10 ` Thomas Gleixner [this message]
2020-10-26 19:04 ` Thomas Gleixner
2020-10-25 13:06 ` Qais Yousef
2020-10-28 15:55 ` Sudeep Holla
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=871rha148x.fsf@nanos.tec.linutronix.de \
--to=tglx@linutronix.de \
--cc=corbet@lwn.net \
--cc=eberman@codeaurora.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=paulmck@kernel.org \
--cc=peterz@infradead.org \
--cc=psodagud@codeaurora.org \
--cc=qais.yousef@arm.com \
--cc=sudeep.holla@arm.com \
--cc=tsoni@codeaurora.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;
as well as URLs for NNTP newsgroup(s).