From: Elliot Berman <eberman@codeaurora.org>
To: Peter Zijlstra <peterz@infradead.org>,
Thomas Gleixner <tglx@linutronix.de>
Cc: "Paul E. McKenney" <paulmck@kernel.org>,
Jonathan Corbet <corbet@lwn.net>,
Trilok Soni <tsoni@codeaurora.org>,
linux-kernel@vger.kernel.org, psodagud@codeaurora.org,
linux-doc@vger.kernel.org, Qais Yousef <qais.yousef@arm.com>
Subject: Re: [PATCH] smp: Add bootcpus parameter to boot subset of CPUs
Date: Tue, 27 Oct 2020 10:06:46 -0700 [thread overview]
Message-ID: <a9fa1f8d-52c7-adca-9087-160b1ecda6b8@codeaurora.org> (raw)
In-Reply-To: <20201026171224.GV2611@hirez.programming.kicks-ass.net>
On 10/26/2020 10:12 AM, Peter Zijlstra wrote:
> On Mon, Oct 26, 2020 at 10:08:47AM -0700, psodagud@codeaurora.org wrote:
>> On 2020-10-23 14:59, Thomas Gleixner wrote:
>>> On Thu, Oct 22 2020 at 15:04, Elliot Berman wrote:
>>>> In a heterogeneous multiprocessor system, specifying the 'maxcpus'
>>>> parameter on kernel command line does not provide sufficient control
>>>> over which CPUs are brought online at kernel boot time, since CPUs may
>>>> have nonuniform performance characteristics. Thus, add bootcpus kernel
>>>> parameter to control which CPUs should be brought online during kernel
>>>> boot. When both maxcpus and bootcpus is set, the more restrictive of
>>>> the
>>>> two are booted.
>>>
>>> What for? 'maxcpus' is a debug hack at best and outright dangerous on
>>> certain architectures. Why do we need more of that? Just let the machine
>>> boot and offline the CPUs from user space.
>>
>> Hi Thomas and Peter,
>>
>> Based on my understanding with maxcpus option provides, maximum no of CPUs
>> are brough up during the device boot up. There is a different case, in which
>> we want to restrict which CPUs to be brough up.
>> On a system with 8 cpus, if we set maxcpus as 3, cpu0, cpu1, and cpu2 are
>> brough up during the bootup. For example, if we want to bring core0, core3
>> and core4 current maxcpu(as 3) setting would not help us.
>> On some platform we want the flexibility on which CPUs to bring up during
>> the device bootup. bootcpus command line is helping to bring specific CPUs
>> and these patches are working downstream.
>
> That's a lot of words, but exactly 0 on _WHY_ you would want to do that.
>
We find the ability to limit the number of cpus brought online at bootup
useful, and to possibly later enable those cores. One use case is when
device is undergoing initial testing is to use bootcpus to limit bootup
to only a couple cores and later bring up the other cores for a
controlled stress test. A core brought up during boot is also running
device initialization. Besides being useful for SoC vendor bringup which
typically occurs downstream, this particular use case could be exercised
by developer of upstream support for a SoC when initial CPU settings are
being determined.
Another use case is if user wishes to limit bootup only to the smaller
or bigger cores. maxcpus= is not sufficient here to ensure that only
those cores are booted since it limits only to the first N cores, which
may not be the desired small or big cores. User may want to bring up
only the smaller cores during bootup for thermal reasons. For instance,
device may be later sufficiently charged such that boot up of the bigger
cores is now permissible. Relying on thermal drivers to later take care
of putting core into lower power idle may not occur until much later in
boot (for instance, if the governor is a module).
next prev parent reply other threads:[~2020-10-27 17:08 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-22 22:04 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 [this message]
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
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=a9fa1f8d-52c7-adca-9087-160b1ecda6b8@codeaurora.org \
--to=eberman@codeaurora.org \
--cc=corbet@lwn.net \
--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=tglx@linutronix.de \
--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
Powered by JetHome