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: <bhjq4yxo7fvddq3kvvvbgefhyaygb5bwkzhsjp3adc5kp7ohtx@iclghpep3zkw>
Date:   Fri, 2 Jun 2023 09:34:03 +0200
From:   Maxime Ripard <mripard@...nel.org>
To:     Jernej Škrabec <jernej.skrabec@...il.com>
Cc:     Frank Oltmanns <frank@...manns.dev>,
        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

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.

Maxime

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)