linux-kernel - Re: [RFC RESEND 0/3] Introduce cpufreq minimum load QoS

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 for Android: free password hash cracker in your pocket

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

Message-ID: <ab4340c0-bda3-e752-9073-e162e6325bb1@st.com>
Date:   Wed, 27 May 2020 11:17:09 +0000
From:   Benjamin GAIGNARD <benjamin.gaignard@...com>
To:     Valentin Schneider <valentin.schneider@....com>
CC:     "rjw@...ysocki.net" <rjw@...ysocki.net>,
        "viresh.kumar@...aro.org" <viresh.kumar@...aro.org>,
        Hugues FRUCHET <hugues.fruchet@...com>,
        "mchehab@...nel.org" <mchehab@...nel.org>,
        "mcoquelin.stm32@...il.com" <mcoquelin.stm32@...il.com>,
        Alexandre TORGUE <alexandre.torgue@...com>,
        "pavel@....cz" <pavel@....cz>,
        "len.brown@...el.com" <len.brown@...el.com>,
        "vincent.guittot@...aro.org" <vincent.guittot@...aro.org>,
        "linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-media@...r.kernel.org" <linux-media@...r.kernel.org>,
        "linux-stm32@...md-mailman.stormreply.com" 
        <linux-stm32@...md-mailman.stormreply.com>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [RFC RESEND 0/3] Introduce cpufreq minimum load QoS



On 5/27/20 12:09 PM, Valentin Schneider wrote:
> Hi Benjamin,
>
> On 26/05/20 16:16, Benjamin Gaignard wrote:
>> A first round [1] of discussions and suggestions have already be done on
>> this series but without found a solution to the problem. I resend it to
>> progress on this topic.
>>
> Apologies for sleeping on that previous thread.
>
> So what had been suggested over there was to use uclamp to boost the
> frequency of the handling thread; however if you use threaded IRQs you
> get RT threads, which already get the max frequency by default (at least
> with schedutil).
>
> Does that not work for you, and if so, why?
That doesn't work because almost everything is done by the hardware blocks
without charge the CPU so the thread isn't running. I have done the 
tests with schedutil
and ondemand scheduler (which is the one I'm targeting). I have no 
issues when using
performance scheduler because it always keep the highest frequencies.


>
>> When start streaming from the sensor the CPU load could remain very low
>> because almost all the capture pipeline is done in hardware (i.e. without
>> using the CPU) and let believe to cpufreq governor that it could use lower
>> frequencies. If the governor decides to use a too low frequency that
>> becomes a problem when we need to acknowledge the interrupt during the
>> blanking time.
>> The delay to ack the interrupt and perform all the other actions before
>> the next frame is very short and doesn't allow to the cpufreq governor to
>> provide the required burst of power. That led to drop the half of the frames.
>>
>> To avoid this problem, DCMI driver informs the cpufreq governors by adding
>> a cpufreq minimum load QoS resquest.
>>
>> Benjamin
>>
>> [1] https://lkml.org/lkml/2020/4/24/360
>>
>> Benjamin Gaignard (3):
>>    PM: QoS: Introduce cpufreq minimum load QoS
>>    cpufreq: governor: Use minimum load QoS
>>    media: stm32-dcmi: Inform cpufreq governors about cpu load needs
>>
>>   drivers/cpufreq/cpufreq_governor.c        |   5 +
>>   drivers/media/platform/stm32/stm32-dcmi.c |   8 ++
>>   include/linux/pm_qos.h                    |  12 ++
>>   kernel/power/qos.c                        | 213 ++++++++++++++++++++++++++++++
>>   4 files changed, 238 insertions(+)