Re: [PATCH] Documentation: admin-guide: pm: cpufreq: fix sampling_rate example command

[Zhongqiu Han]

On 6/21/2026 11:52 AM, Randy Dunlap wrote:
> On 6/20/26 7:25 PM, wangxiaodong wrote:
> > The example shell command for setting ondemand's sampling_rate wraps an
> > arithmetic expansion $((...)) in command-substitution backticks. The
> > arithmetic result is then executed as a command, which fails and writes
> > an empty value. Drop the surrounding backticks so the computed value is
> > passed to echo as intended.
> >
> > Signed-off-by: wangxiaodong <wangxiaodong827546786@xxxxxxxxx>
> > ---
> >   Documentation/admin-guide/pm/cpufreq.rst | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/Documentation/admin-guide/pm/cpufreq.rst b/Documentation/admin-guide/pm/cpufreq.rst
> > index 8831cface585..34baf20cc202 100644
> > --- a/Documentation/admin-guide/pm/cpufreq.rst
> > +++ b/Documentation/admin-guide/pm/cpufreq.rst
> > @@ -497,7 +497,7 @@ This governor exposes the following tunables:
> >   	represented by it to be 1.5 times as high as the transition latency
> >   	(the default)::
> >   
> > -	# echo `$(($(cat cpuinfo_transition_latency) * 3 / 2))` > ondemand/sampling_rate
> > +	# echo $(($(cat cpuinfo_transition_latency) * 3 / 2)) > ondemand/sampling_rate
>
> Ugh. Thanks.
> Reviewed-by: Randy Dunlap <rdunlap@xxxxxxxxxxxxx>
>
> and possibly:
> Fixes: e54ac586674d ("cpufreq: editing corrections to cpufreq.rst")


Thanks Randy,

Just to back up Randy's Fixes suggestion, the line evolved as follows
(most recent first):

2025/04/04 e54ac586674d:  #echo `$((.. * 3 / 2))` >  (trailing ` added)
2024/10/17 29dcbea92460:  #echo `$((.. * 3 / 2))  >  (still dangling `)
2017/03/13 2a0e49279850:  #echo `$((.. * 750 / 1000)) > (dangling leading `)

The stray backtick can be traced back to 2a0e49279850, but it was just a
dangling backtick then. The closed command-substitution form fixed here
was only reached after e54ac586674d added the trailing backtick. Note
that the "750/1000 -> 3/2" change in 29dcbea92460 was not just a doc
edit: it reflects an actual change in the kernel's behaviour. So on the
older trees the underlying logic - and hence this documented example -
is genuinely different, and this patch wouldn't apply cleanly there
anyway. Pointing Fixes at 2a0e49279850 therefore wouldn't help
backports.

So using

Fixes: e54ac586674d ("cpufreq: editing corrections to cpufreq.rst")

seems reasonable.

Either way, the fix is fine to me:

Reviewed-by: Zhongqiu Han <zhongqiu.han@xxxxxxxxxxxxxxxx>




> >   
> >   ``up_threshold``
> >   	If the estimated CPU load is above this value (in percent), the governor


--
Thx and BRs,
Zhongqiu Han