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.
