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: <flngzi4henkzcpzwdexencdkw77h52g3nduup7pwctpwfiuznk@eewnnut5mvsq>
Date:   Wed, 31 May 2023 15:48:43 +0200
From:   Maxime Ripard <mripard@...nel.org>
To:     Frank Oltmanns <frank@...manns.dev>
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>,
        Jernej Skrabec <jernej.skrabec@...il.com>,
        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 Frank,

On Sat, May 27, 2023 at 03:27:44PM +0200, Frank Oltmanns wrote:
> I would like to bring your attention to the current process of setting
> the rate of an NKM clock. As it stands, when setting the rate of an
> NKM clock, the rate nearest but less than or equal to the requested
> rate is found, instead of the nearest rate.

Yeah, it's actually pretty common, see clk_mux_determine_rate_flags()
for example. Some devices require that we don't overshoot, while some
prefer to have the closest rate.

Both are fine, and it's a bit context specific which one we should
favour. If we were to do anything, it would be to support both and let
the clock driver select which behaviour it wants.

> Moreover, ccu_nkm_find_best() is called multiple times (footnote [1])
> when setting a rate, each time iterating over all combinations of n,
> k, and m.

Yeah, that's expected as well.

> In response to this, I propose the following refinements to optimize the NKM
> clock setting:
>  a. when finding the best rate use the nearest rate, even if it is greater than
>     the requested rate (PATCH 1)
>  b. utilize binary search to find the best rate by going through a
>     precalculated, ordered list of all meaningful combinations of n, k, and m
>     (PATCH 2)

One thing you haven't really addressed is why we would be doing this? Is
there some clocks that require a more precise clock and don't? Is the
factor calculation a bottleneck for some workloads?

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".

Maxime

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