From: Viresh Kumar <viresh.kumar@linaro.org>
To: Dmitry Osipenko <digetx@gmail.com>
Cc: Viresh Kumar <vireshk@kernel.org>, Nishanth Menon <nm@ti.com>,
Stephen Boyd <sboyd@kernel.org>,
linux-pm@vger.kernel.org,
Vincent Guittot <vincent.guittot@linaro.org>,
Rafael Wysocki <rjw@rjwysocki.net>,
Sibi Sankar <sibis@codeaurora.org>,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>
Subject: Re: [PATCH 07/13] opp: Allow _generic_set_opp_clk_only() to work for non-freq devices
Date: Wed, 27 Jan 2021 12:28:46 +0530 [thread overview]
Message-ID: <20210127065846.c2usquegqrqib45r@vireshk-i7> (raw)
In-Reply-To: <7d6573e3-7885-fb0b-2290-c181e2c557f9@gmail.com>
On 26-01-21, 00:09, Dmitry Osipenko wrote:
> Please remove unlikely() around IS_ERR(), it already has the unlikely().
Right.
> https://elixir.bootlin.com/linux/v5.11-rc4/source/include/linux/err.h#L22
>
> I'd also recommend to remove all the unlikely() from OPP code since it
> doesn't bring any value if not used in a very performance-critical code
> path. OPP core doesn't have such code paths. The [un]likely() only make
> code less readable and may result in a worse assembly.
The likely/unlikely() stuff is to optimize code, not necessarily the stuff in
the hot path alone, therwise stuff like IS_ERR() would never have it. It surely
does bring value by optimizing the code, surely the result isn't significant
enough but that is fine, every effort counts.
AFAIK, if we are sure of path the code will almost always take, then we should
rather use these and so I am inclined towards keeping them. Though I understand
that using them may result in bad behavior (performance) if they fail.
--
viresh
next prev parent reply other threads:[~2021-01-27 7:00 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-21 11:17 [PATCH 00/13] opp: Implement dev_pm_opp_set_opp() Viresh Kumar
2021-01-21 11:17 ` [PATCH 01/13] opp: Rename _opp_set_rate_zero() Viresh Kumar
2021-01-21 11:17 ` [PATCH 02/13] opp: No need to check clk for errors Viresh Kumar
2021-01-21 11:17 ` [PATCH 03/13] opp: Keep track of currently programmed OPP Viresh Kumar
2021-01-21 21:41 ` Dmitry Osipenko
2021-01-22 4:45 ` Viresh Kumar
2021-01-22 14:31 ` Dmitry Osipenko
2021-01-25 3:12 ` Viresh Kumar
2021-01-27 16:31 ` Akhil P Oommen
2021-01-28 4:14 ` Viresh Kumar
2021-07-07 10:24 ` Ionela Voinescu
2021-07-08 7:53 ` Viresh Kumar
2021-07-09 8:57 ` Ionela Voinescu
2021-07-12 4:14 ` Viresh Kumar
2021-01-21 11:17 ` [PATCH 04/13] opp: Split _set_opp() out of dev_pm_opp_set_rate() Viresh Kumar
2021-01-21 11:17 ` [PATCH 05/13] opp: Allow _set_opp() to work for non-freq devices Viresh Kumar
2021-01-21 11:17 ` [PATCH 06/13] opp: Allow _generic_set_opp_regulator() " Viresh Kumar
2021-01-21 11:17 ` [PATCH 07/13] opp: Allow _generic_set_opp_clk_only() " Viresh Kumar
2021-01-21 20:26 ` Dmitry Osipenko
2021-01-22 4:35 ` Viresh Kumar
2021-01-25 21:09 ` Dmitry Osipenko
2021-01-27 6:58 ` Viresh Kumar [this message]
2021-01-21 11:17 ` [PATCH 08/13] opp: Update parameters of _set_opp_custom() Viresh Kumar
2021-01-21 11:17 ` [PATCH 09/13] opp: Implement dev_pm_opp_set_opp() Viresh Kumar
2021-01-21 11:17 ` [PATCH 10/13] cpufreq: qcom: Migrate to dev_pm_opp_set_opp() Viresh Kumar
2021-01-21 11:17 ` [PATCH 11/13] devfreq: tegra30: " Viresh Kumar
2021-01-21 21:36 ` Dmitry Osipenko
2021-01-22 6:26 ` Viresh Kumar
2021-01-22 15:28 ` Dmitry Osipenko
2021-01-25 3:14 ` Viresh Kumar
2021-01-25 16:00 ` Dmitry Osipenko
2021-01-27 9:10 ` [PATCH V2 " Viresh Kumar
2021-01-27 10:02 ` Viresh Kumar
2021-01-27 15:58 ` Dmitry Osipenko
2021-01-28 7:01 ` Viresh Kumar
2021-02-01 0:21 ` Chanwoo Choi
2021-02-01 19:57 ` Dmitry Osipenko
2021-01-21 11:17 ` [PATCH 12/13] drm: msm: " Viresh Kumar
2021-01-21 11:17 ` [PATCH 13/13] opp: Remove dev_pm_opp_set_bw() Viresh Kumar
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=20210127065846.c2usquegqrqib45r@vireshk-i7 \
--to=viresh.kumar@linaro.org \
--cc=digetx@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=nm@ti.com \
--cc=rjw@rjwysocki.net \
--cc=sboyd@kernel.org \
--cc=sibis@codeaurora.org \
--cc=vincent.guittot@linaro.org \
--cc=vireshk@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;
as well as URLs for NNTP newsgroup(s).