Hi Doug
> On Feb 19, 2016, at 5:38 PM, Doug Smythies <[email protected]> wrote: > > Hi Steph, > > On 2016.02.19 03:12 Stephane Gasparini wrote: >> >> The issue you are reporting looks like one we improved on android by using >> the average pstate instead of using the last requested pstate >> >> We know that this is improving the ffmpeg encoding performance when using the >> load algorithm. >> >> see patch attached >> >> This patch is only applied on get_target_pstate_use_cpu_load however you can >> give >> it a try on get_target_pstate_use_performance > > Yes, that type of patch works on the load based approach. > I’m not talking about using average p-state in the scaled_busy computation. I’m talking adding the output of the PID (the number of pstate to ad or subtract) to the average pstate rather than adding this to the current p-sate. The current p-state is in some situation not reflecting the reality as the current p-state can be imposed by a "linked CPU". This is the case when you have a thread migration on "linked CPU" that was not loaded. Its current P-State will be low while its average p-state will reflect the activity of the "linked CPU". I will not claim this is a perfect solution, but this combined to the topology awareness of the scheduler is helping to take better decision. > However, I do not think it works on the performance based approach. Why not? > Well, and if I understand correctly, follow the math and you end up with: > > scaled_busy = 100% > > scaled_busy = (aperf * 100% / mperf) * (max_pstate / * ((aperf * max_pstate) > / mperf)) > > ... Doug > > — Steph
