Hi Krzysztof,
On 1/31/20 8:41 PM, Krzysztof Kozlowski wrote:
On Fri, Jan 31, 2020 at 05:30:46PM +0000, Lukasz Luba wrote:
|-----------------------------------------------|---------------
| performance | SchedUtil | SchedUtil | performance
| governor | governor | governor | governor
| | w/o EAS | w/ EAS |
----------------|---------------|---------------|---------------|---------------
hackbench w/ PL | 12.7s | 11.7s | 12.0s | 13.0s - 12.2s
hackbench w/o PL| 9.2s | 8.1s | 8.2s | 9.2s - 8.4s
Why does the performance different before and after this patch?
Probably due to better locality and cache utilization. I can see that
there is ~700k context switches vs ~450k and ~160k migrations vs ~50k.
If you need to communicate two threads in different clusters, it will go
through CCI.
Mhmm... I was not specific - I mean, "performance governor". All this
you mentioned should not differ between performance governor before and
after. However once you have 12.7, then 13.0 - 12.2. Unless multi-core
scheduler affects it... but then these numbers here are not showing
only this change, but also the SCHED_MC effect. In such case each of
commits should be coming with their own numbers.
Agree, I should have not put 'this patch set' in the commit
msg. It should go into the cover letter and avoid this confusion.
You are right with ' Unless multi-core scheduler affects it...',
that's why when the SCHED_MC is missing, the decisions about task
placing might cause this variation and delay '13.0 - 12.2' seconds.
As mentioned in response to patch 1/3. The fist patch would create MC
domain, something different than Energy Model or EAS. The decisions in
the scheduler would be different.
I can merge 1/3 and 3/3 if you like, though.
I understand now that their independent. Still, they are part of one
goal to tune the scheduler for Exynos platform. Splitting these looks
too much, like enabling multiple drivers one after another.
However if you provide numbers for each of cases (before patches, multi
core scheduler, energy model with DTS), then I see benefit of splitting
it. Each commit would have its own rationale. I am not sure if it is
worth such investigation - that's just defconfig... distros might ignore
it anyway.
Good point, and I agree that it would require more investigation, for
which unfortunately I don't have currently spare cycles.
Should I merge patch 1/3 and 3/3 and send the v2 with a cover letter
which would have the test results?
Regards,
Lukasz
