On 4/30/20 11:03 AM, Rafael J. Wysocki wrote: > On Thu, Apr 30, 2020 at 9:53 AM Benjamin GAIGNARD > <benjamin.gaignard@xxxxxx> 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.
