mbox series

[RFC,0/3] Introduce cpufreq minimum load QoS

Message ID 20200424114058.21199-1-benjamin.gaignard@st.com (mailing list archive)
Headers show
Series Introduce cpufreq minimum load QoS | expand

Message

Benjamin GAIGNARD April 24, 2020, 11:40 a.m. UTC
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 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(+)

Comments

Rafael J. Wysocki April 29, 2020, 3:50 p.m. UTC | #1
On Friday, April 24, 2020 1:40:55 PM CEST Benjamin Gaignard wrote:
> 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.

This seems to be addressing a use case that can be addressed with the help of
utilization clamps with less power overhead.

Thanks!
Benjamin GAIGNARD April 29, 2020, 3:57 p.m. UTC | #2
On 4/29/20 5:50 PM, Rafael J. Wysocki wrote:
> On Friday, April 24, 2020 1:40:55 PM CEST Benjamin Gaignard wrote:
>> 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.
> This seems to be addressing a use case that can be addressed with the help of
> utilization clamps with less power overhead.
Do mean clamping the policy frequencies ? I may have miss the API to do 
that...
>
> Thanks!
>
>
>
Valentin Schneider April 29, 2020, 4:12 p.m. UTC | #3
On 29/04/2020 16:57, Benjamin GAIGNARD wrote:
> 
> 
> On 4/29/20 5:50 PM, Rafael J. Wysocki wrote:
>> On Friday, April 24, 2020 1:40:55 PM CEST Benjamin Gaignard wrote:
>>> 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.
>> This seems to be addressing a use case that can be addressed with the help of
>> utilization clamps with less power overhead.
> Do mean clamping the policy frequencies ? I may have miss the API to do 
> that...
>>

IIUC Rafael is referring to uclamp, i.e. scheduler utilization clamping, see:

  https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html#cpu

The above describes the cgroup interface, note that you can also set clamps
per task (via sched_setattr()).

One thing that comes to mind however is that schedutil only "sees" the clamps
of runnable tasks, and from reading your changelog you may not have moments
without any (i.e. gears are grinding in HW). You'd have to try boosting
(setting a high uclamp.min) whatever tasks you have on the software side and
see how it all behaves.

>> Thanks!
>>
>>
>>
Vincent Guittot April 29, 2020, 5:08 p.m. UTC | #4
On Wed, 29 Apr 2020 at 17:50, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
>
> On Friday, April 24, 2020 1:40:55 PM CEST Benjamin Gaignard wrote:
> > 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.
>
> This seems to be addressing a use case that can be addressed with the help of
> utilization clamps with less power overhead.

Can't freq_qos_update_request() be also used if you don't have cgroup
enabled on your system ?

>
> Thanks!
>
>
>
Benjamin GAIGNARD April 30, 2020, 7:52 a.m. UTC | #5
On 4/29/20 6:12 PM, Valentin Schneider wrote:
> On 29/04/2020 16:57, Benjamin GAIGNARD wrote:
>>
>> On 4/29/20 5:50 PM, Rafael J. Wysocki wrote:
>>> On Friday, April 24, 2020 1:40:55 PM CEST Benjamin Gaignard wrote:
>>>> 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.
>>> This seems to be addressing a use case that can be addressed with the help of
>>> utilization clamps with less power overhead.
>> Do mean clamping the policy frequencies ? I may have miss the API to do
>> that...
> IIUC Rafael is referring to uclamp, i.e. scheduler utilization clamping, see:
>
>    https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html#cpu
>
> The above describes the cgroup interface, note that you can also set clamps
> per task (via sched_setattr()).
>
> One thing that comes to mind however is that schedutil only "sees" the clamps
> of runnable tasks, and from reading your changelog you may not have moments
> without any (i.e. gears are grinding in HW). You'd have to try boosting
> (setting a high uclamp.min) whatever tasks you have on the software side and
> see how it all behaves.
Relying on userland side means that various applications need to be aware
of this specific hardware case and fix it. I was hoping to find a 
solution in side the kernel
to not impact the software side.

>
>>> Thanks!
>>>
>>>
>>>
Rafael J. Wysocki April 30, 2020, 9 a.m. UTC | #6
On Wed, Apr 29, 2020 at 7:08 PM Vincent Guittot
<vincent.guittot@linaro.org> wrote:
>
> On Wed, 29 Apr 2020 at 17:50, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> >
> > On Friday, April 24, 2020 1:40:55 PM CEST Benjamin Gaignard wrote:
> > > 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.
> >
> > This seems to be addressing a use case that can be addressed with the help of
> > utilization clamps with less power overhead.
>
> Can't freq_qos_update_request() be also used if you don't have cgroup
> enabled on your system ?

It can.

The problem here is that imposing a global minimum frequency limit
generally causes the power draw of the system to increase regardless
of what is going on, including the CPUs that are not involved in the
handling of the interrupt in question.

That seems a bit excessive ...
Rafael J. Wysocki April 30, 2020, 9:03 a.m. UTC | #7
On Thu, Apr 30, 2020 at 9:53 AM Benjamin GAIGNARD
<benjamin.gaignard@st.com> wrote:
>
>
>
> On 4/29/20 6:12 PM, Valentin Schneider wrote:
> > On 29/04/2020 16:57, Benjamin GAIGNARD wrote:
> >>
> >> On 4/29/20 5:50 PM, Rafael J. Wysocki wrote:
> >>> On Friday, April 24, 2020 1:40:55 PM CEST Benjamin Gaignard wrote:
> >>>> 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.
> >>> This seems to be addressing a use case that can be addressed with the help of
> >>> utilization clamps with less power overhead.
> >> Do mean clamping the policy frequencies ? I may have miss the API to do
> >> that...
> > IIUC Rafael is referring to uclamp, i.e. scheduler utilization clamping, see:
> >
> >    https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html#cpu
> >
> > The above describes the cgroup interface, note that you can also set clamps
> > per task (via sched_setattr()).
> >
> > One thing that comes to mind however is that schedutil only "sees" the clamps
> > of runnable tasks, and from reading your changelog you may not have moments
> > without any (i.e. gears are grinding in HW). You'd have to try boosting
> > (setting a high uclamp.min) whatever tasks you have on the software side and
> > see how it all behaves.
>
> Relying on userland side means that various applications need to be aware
> of this specific hardware case and fix it. I was hoping to find a
> solution in side the kernel
> to not impact the software side.

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.

Alternatively, that task may be a deadline one.
Benjamin GAIGNARD April 30, 2020, 1:46 p.m. UTC | #8
On 4/30/20 11:03 AM, Rafael J. Wysocki wrote:
> On Thu, Apr 30, 2020 at 9:53 AM Benjamin GAIGNARD
> <benjamin.gaignard@st.com> wrote:
>>
>>
>> On 4/29/20 6:12 PM, Valentin Schneider wrote:
>>> On 29/04/2020 16:57, Benjamin GAIGNARD wrote:
>>>> On 4/29/20 5:50 PM, Rafael J. Wysocki wrote:
>>>>> On Friday, April 24, 2020 1:40:55 PM CEST Benjamin Gaignard wrote:
>>>>>> 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.
>>>>> This seems to be addressing a use case that can be addressed with the help of
>>>>> utilization clamps with less power overhead.
>>>> Do mean clamping the policy frequencies ? I may have miss the API to do
>>>> that...
>>> IIUC Rafael is referring to uclamp, i.e. scheduler utilization clamping, see:
>>>
>>>     https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html#cpu
>>>
>>> The above describes the cgroup interface, note that you can also set clamps
>>> per task (via sched_setattr()).
>>>
>>> One thing that comes to mind however is that schedutil only "sees" the clamps
>>> of runnable tasks, and from reading your changelog you may not have moments
>>> without any (i.e. gears are grinding in HW). You'd have to try boosting
>>> (setting a high uclamp.min) whatever tasks you have on the software side and
>>> see how it all behaves.
>> Relying on userland side means that various applications need to be aware
>> of this specific hardware case and fix it. I was hoping to find a
>> solution in side the kernel
>> to not impact the software side.
> 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 */
         .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 ?

>
> Alternatively, that task may be a deadline one.
Valentin Schneider April 30, 2020, 2:33 p.m. UTC | #9
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.

>>
>> Alternatively, that task may be a deadline one.
Benjamin GAIGNARD April 30, 2020, 3:37 p.m. UTC | #10
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.
- 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.
Valentin Schneider April 30, 2020, 3:50 p.m. UTC | #11
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).

> - 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.
Benjamin GAIGNARD May 4, 2020, 9:17 a.m. UTC | #12
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.
Benjamin GAIGNARD May 20, 2020, 7:29 a.m. UTC | #13
On 5/4/20 11:17 AM, Benjamin GAIGNARD wrote:
>
> 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 ?
Gentle up on this series beacause I haven't found any other way to solve
this problem.

Thanks,
Benjamin
>
>>> - 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.
> _______________________________________________
> Linux-stm32 mailing list
> Linux-stm32@st-md-mailman.stormreply.com
> https://st-md-mailman.stormreply.com/mailman/listinfo/linux-stm32