linux-kernel - Re: [RFC PATCH 0/3] clk: sunxi-ng: Optimize rate selection for NKM clocks

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <877csi9lwi.fsf@oltmanns.dev>
Date:   Mon, 05 Jun 2023 13:41:17 +0200
From:   Frank Oltmanns <frank@...manns.dev>
To:     Jernej Škrabec <jernej.skrabec@...il.com>,
        Maxime Ripard <mripard@...nel.org>
Cc:     linux-arm-kernel@...ts.infradead.org, linux-clk@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-sunxi@...ts.linux.dev,
        Andre Przywara <andre.przywara@....com>,
        Chen-Yu Tsai <wens@...e.org>, Icenowy Zheng <icenowy@...c.io>,
        Michael Turquette <mturquette@...libre.com>,
        Rob Herring <robh@...nel.org>,
        Samuel Holland <samuel@...lland.org>,
        Stephen Boyd <sboyd@...nel.org>
Subject: Re: [RFC PATCH 0/3] clk: sunxi-ng: Optimize rate selection for NKM
 clocks

Hi Jernej,
hi Maxime,

On 2023-06-02 at 09:34:03 +0200, Maxime Ripard <mripard@...nel.org> wrote:
> [[PGP Signed Part:Undecided]]
> On Thu, Jun 01, 2023 at 09:41:30PM +0200, Jernej Škrabec wrote:
>> Dne četrtek, 01. junij 2023 ob 07:16:45 CEST je Frank Oltmanns napisal(a):
>> > Re: Why speed up factor calculation?
>> > ====================================
>> > I'm not aware that the current implementation of calculating n, k, and m
>> > poses a bottleneck in any situation. Again, while going through the
>> > code, I wondered why not save a few CPU cycles by precalculating the
>> > meaningful combinations. In my opinion, it does not have any side
>> > effects, so we might as well do it. (There is of course the side effect
>> > of using a higher rate, but this is unrelated to precalculation as I
>> > could as well employ a rate comparison that only allows lower rates, or
>> > only optionally higher rates.)
>> >
>> > > Clocks in general are very regression-prone, so I'd rather be a bit
>> > > conservative there, and "if it ain't broke, don't fix it".
>> >
>> > Sure, I get that.
>> >
>> > As I stated in my cover letter:
>> > "The motivation for these proposed changes lies in the current behavior
>> > of rate selection for NKM clocks, which doesn't observe the
>> > CLK_SET_RATE_PARENT flag. I.e. it does not select a different rate for
>> > the parent clock to find the optimal rate."
>> >
>> > I thought that this required this optimization to be implemented, but by
>> > now, I'm no longer sure. I'll probably continue investigating different
>> > paths for CLK_SET_RATE_PARENT for NKM clocks and follow up with new
>> > findings.
>>
>> Let's leave out any optimizations that are not apparently needed. Most clock
>> rates are set only once at boot and others, like video clocks, not that often,
>> so a suboptimal code speed doesn't hurt currently.
>
> I'm not even sure we can make that assumption for video clocks. We might
> for a panel, but for a more "dynamic" output like HDMI all bets are off
> and depending on the monitor, the user settings and the userspace stack
> we can definitely expect the video clock to change quite frequently.

Thank you both for your valuable feedback!

The goal I head in mind was adjusting pll-video0's clock when setting
DCLK on Allwinner A64. And you're both right, I got sidetracked by
premature optimizations.

As I wrote elsewhere in this thread, I will submit a patchset for the
original goal and we can discuss potential needs for optimization there.

Thanks,
  Frank

>
> Maxime
>
> [[End of PGP Signed Part]]