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]
Date:   Wed, 26 Jul 2023 19:19:34 +0200
From:   Konrad Dybcio <konrad.dybcio@...aro.org>
To:     Stephan Gerhold <stephan@...hold.net>
Cc:     Andy Gross <agross@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Georgi Djakov <djakov@...nel.org>,
        Marijn Suijten <marijn.suijten@...ainline.org>,
        linux-arm-msm@...r.kernel.org, linux-pm@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/4] interconnect: qcom: icc-rpm: Add AB/IB calculations
 coefficients

On 26.07.2023 19:16, Stephan Gerhold wrote:
> On Wed, Jul 26, 2023 at 06:25:43PM +0200, Konrad Dybcio wrote:
>> Presumably due to the hardware being so complex, some nodes (or busses)
>> have different (usually higher) requirements for bandwidth than what
>> the usual calculations would suggest.
>>
> 
> Weird. I just hope this was never abused to workaround other broken
> configuration. A nice round ib_percent = 200 has mostly the same effect as
> 
>   - Doubling the requested peek bandwidth in the consumer driver (perhaps
>     they were too lazy to fix the driver in downstream at some point)
>   - Halving the node buswidth
> 
> It's probably hard to say for sure...
As per usual..

[...]

>>  
>>  	/*
>> @@ -315,6 +317,12 @@ static void qcom_icc_bus_aggregate(struct icc_provider *provider, u64 *agg_clk_r
>>  			else
>>  				agg_avg_rate = qn->sum_avg[i];
>>  
>> +			percent = qp->ab_percent ? qp->ab_percent : 100;
>> +			agg_avg_rate = mult_frac(percent, agg_avg_rate, 100);
> 
> 			if (qp->ab_percent)
> 				agg_avg_rate = mult_frac(qp->ab_percent, agg_avg_rate, 100);
> 
> Would be likely more efficient (no calculation if unspecified) and not
> much harder to read.
Oh right!

> 
>> +
>> +			percent = qn->ib_percent ? qn->ib_percent : 100;
>> +			agg_peak_rate = mult_frac(percent, qn->max_peak[i], 100);
>> +
> 
> agg_peak_rate doesn't seem to be used anywhere else? 🤔
Whoooooops....

Konrad

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ