From: Quentin Perret <qperret@google.com>
To: "zhuguangqing83" <zhuguangqing83@gmail.com>
Cc: <lukasz.luba@arm.com>, <rjw@rjwysocki.net>, <pavel@ucw.cz>,
<len.brown@intel.com>, <linux-pm@vger.kernel.org>,
<linux-kernel@vger.kernel.org>,
"'zhuguangqing'" <zhuguangqing@xiaomi.com>
Subject: Re: [PATCH] PM / EM: consult something about cpumask in em_dev_register_perf_domain
Date: Tue, 13 Oct 2020 16:20:42 +0100 [thread overview]
Message-ID: <20201013152042.GA183119@google.com> (raw)
In-Reply-To: <098a01d6a112$9cd7f410$d687dc30$@gmail.com>
On Tuesday 13 Oct 2020 at 11:40:31 (+0800), zhuguangqing83 wrote:
> I did not observe anything wrong for my use-case. But I think it's possible
> in
> theory that cpu_dev maybe NULL. I observe that in the function
> scmi_cpufreq_init(), before calling em_dev_register_perf_domain(),
> 'policy->cpus' can be ensure that all the cpu_dev in CPU mask are not NULL.
> But maybe we can not ensure all the clients do the check. This could happen
> if the arch did not set up cpu_dev since this CPU is not in cpu_present mask
> and the driver did not send a correct CPU mask during registration.
Admittedly this has only been tested on Arm64 where I think we can
safely assume that all possible CPUs have been registered at once -- see
topology_init().
And for allowing to register CPUs late in a perf domain, I'm not opposed
to it in principle but that has deep implications as the existing EM
users (e.g. EAS) currently hard rely on it being static after
registration. If you have a real need for it and a patch that adds the
feature and fixes all the users I'll be happy to look at it :)
Thanks,
Quentin
next prev parent reply other threads:[~2020-10-13 15:20 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-13 3:40 [PATCH] PM / EM: consult something about cpumask in em_dev_register_perf_domain zhuguangqing83
2020-10-13 15:20 ` Quentin Perret [this message]
-- strict thread matches above, loose matches on Subject: below --
2020-10-12 12:41 zhuguangqing83
2020-10-12 13:05 ` Quentin Perret
2020-10-12 13:10 ` Quentin Perret
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=20201013152042.GA183119@google.com \
--to=qperret@google.com \
--cc=len.brown@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=lukasz.luba@arm.com \
--cc=pavel@ucw.cz \
--cc=rjw@rjwysocki.net \
--cc=zhuguangqing83@gmail.com \
--cc=zhuguangqing@xiaomi.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.