linux-kernel - Re: [RFC 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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Mon, 4 May 2020 09:17:41 +0000
From:   Benjamin GAIGNARD <benjamin.gaignard@...com>
To:     Valentin Schneider <valentin.schneider@....com>
CC:     "Rafael J. Wysocki" <rafael@...nel.org>,
        "Rafael J. Wysocki" <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>,
        "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>,
        Patrick Bellasi <patrick.bellasi@....com>
Subject: Re: [RFC 0/3] Introduce cpufreq minimum load QoS



On 4/30/20 5:50 PM, Valentin Schneider wrote:
> On 30/04/20 16:37, Benjamin GAIGNARD wrote:
>> On 4/30/20 4:33 PM, Valentin Schneider wrote:
>>> On 30/04/20 14:46, Benjamin GAIGNARD wrote:
>>>>> That's not what I meant.
>>>>>
>>>>> I suppose that the interrupt processing in question takes place in
>>>>> process context and so you may set the lower clamp on the utilization
>>>>> of the task carrying that out.
>>>> I have try to add this code when starting streaming (before the first
>>>> interrupt) the frames from the sensor:
>>>> const struct sched_attr sched_attr = {
>>>>      .sched_util_min = 10000, /* 100% of usage */
>>> Unless you play with SCHED_CAPACITY_SHIFT, the max should be 1024 -
>>> i.e. SCHED_CAPACITY_SCALE. That's a really big boost, but that's for you to
>>> benchmark.
>>>
>>>>      .sched_flags = SCHED_FLAG_UTIL_CLAMP_MIN,
>>>>     };
>>>>
>>>> sched_setattr(current, &sched_attr);
>>>>
>>>> I don't see any benefices maybe there is some configuration flags to set.
>>>>
>>>> How changing sched_util_min could impact cpufreq ondemand governor ?
>>>> Does it change the value returned when the governor check the idle time ?
>>>>
>>> You'll have to use the schedutil governor for uclamp to have an effect. And
>>> arguably that's what you should be using, unless something explicitly
>>> prevents you from doing that.
>> Even with schedutil and SCHED_CAPACITY_SCALE that it doesn't work.
>> cpufreq/cpuinfo_cur_freq values are always on the max value even if the
>> stats show transitions between the available frequencies.
>>
>> I see two possibles reasons to explain that:
>> - sched_setattr() is called in userland process context, but the
>> threaded irq handler is running in another process.
> Ah yes, this only works if the task you boost is the one that will handle
> whatever work you care about (in this case handling the irq). That said, if
> you do use threaded IRQs, that should give you a SCHED_FIFO thread, which
> should drive the frequency to its max when using schedutil (unrelated to
> uclamp).
Can I conclude that sched_setattr() isn't the good way to solve this 
problem ?
Does my patches make sense in this case ?

>> - because this use case is almost running all in hardware the process
>> isn't doing anything so the scheduler doesn't take care of it.
>>
>>>>> Alternatively, that task may be a deadline one.