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
WARNING: multiple messages have this Message-ID (diff)
From: Viresh Kumar <viresh.kumar@linaro.org> To: Dmitry Osipenko <digetx@gmail.com> Cc: Nishanth Menon <nm@ti.com>, Vincent Guittot <vincent.guittot@linaro.org>, linux-pm@vger.kernel.org, Stephen Boyd <sboyd@kernel.org>, Viresh Kumar <vireshk@kernel.org>, Rafael Wysocki <rjw@rjwysocki.net>, linux-kernel@vger.kernel.org, Sibi Sankar <sibis@codeaurora.org>, "linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>, linux-arm-kernel@lists.infradead.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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-01-27 7:00 UTC|newest] Thread overview: 73+ 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 ` Viresh Kumar 2021-01-21 11:17 ` Viresh Kumar 2021-01-21 11:17 ` [PATCH 01/13] opp: Rename _opp_set_rate_zero() Viresh Kumar 2021-01-21 11:17 ` 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 ` Viresh Kumar 2021-01-21 11:17 ` [PATCH 03/13] opp: Keep track of currently programmed OPP Viresh Kumar 2021-01-21 11:17 ` Viresh Kumar 2021-01-21 21:41 ` Dmitry Osipenko 2021-01-21 21:41 ` Dmitry Osipenko 2021-01-22 4:45 ` Viresh Kumar 2021-01-22 4:45 ` Viresh Kumar 2021-01-22 14:31 ` Dmitry Osipenko 2021-01-22 14:31 ` Dmitry Osipenko 2021-01-25 3:12 ` Viresh Kumar 2021-01-25 3:12 ` Viresh Kumar 2021-01-27 16:31 ` Akhil P Oommen 2021-01-28 4:14 ` Viresh Kumar 2021-01-28 4:14 ` Viresh Kumar 2021-07-07 10:24 ` Ionela Voinescu 2021-07-07 10:24 ` Ionela Voinescu 2021-07-08 7:53 ` Viresh Kumar 2021-07-08 7:53 ` Viresh Kumar 2021-07-09 8:57 ` Ionela Voinescu 2021-07-09 8:57 ` Ionela Voinescu 2021-07-12 4:14 ` Viresh Kumar 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 ` 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 ` Viresh Kumar 2021-01-21 11:17 ` [PATCH 06/13] opp: Allow _generic_set_opp_regulator() " Viresh Kumar 2021-01-21 11:17 ` Viresh Kumar 2021-01-21 11:17 ` [PATCH 07/13] opp: Allow _generic_set_opp_clk_only() " Viresh Kumar 2021-01-21 11:17 ` Viresh Kumar 2021-01-21 20:26 ` Dmitry Osipenko 2021-01-21 20:26 ` Dmitry Osipenko 2021-01-22 4:35 ` Viresh Kumar 2021-01-22 4:35 ` Viresh Kumar 2021-01-25 21:09 ` Dmitry Osipenko 2021-01-25 21:09 ` Dmitry Osipenko 2021-01-27 6:58 ` Viresh Kumar [this message] 2021-01-27 6:58 ` Viresh Kumar 2021-01-21 11:17 ` [PATCH 08/13] opp: Update parameters of _set_opp_custom() Viresh Kumar 2021-01-21 11:17 ` Viresh Kumar 2021-01-21 11:17 ` [PATCH 09/13] opp: Implement dev_pm_opp_set_opp() Viresh Kumar 2021-01-21 11:17 ` 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 ` Viresh Kumar 2021-01-21 11:17 ` [PATCH 11/13] devfreq: tegra30: " Viresh Kumar 2021-01-21 11:17 ` Viresh Kumar 2021-01-21 21:36 ` Dmitry Osipenko 2021-01-21 21:36 ` Dmitry Osipenko 2021-01-22 6:26 ` Viresh Kumar 2021-01-22 6:26 ` Viresh Kumar 2021-01-22 15:28 ` Dmitry Osipenko 2021-01-22 15:28 ` Dmitry Osipenko 2021-01-25 3:14 ` Viresh Kumar 2021-01-25 3:14 ` Viresh Kumar 2021-01-25 16:00 ` Dmitry Osipenko 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 ` Viresh Kumar 2021-01-21 11:17 ` Viresh Kumar 2021-01-21 11:17 ` [PATCH 13/13] opp: Remove dev_pm_opp_set_bw() Viresh Kumar 2021-01-21 11:17 ` 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: linkBe 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.