On 13-Oct 15:18, Vincent Guittot wrote:
On 13 October 2016 at 15:05, Patrick Bellasi patrick.bellasi@arm.com wrote:
On 10-Oct 16:35, Leo Yan wrote:
Add extra two performance optimization methods by setting sysfs nodes:
Method 1: set sched_migration_cost_ns to 0:
By default sched_migration_cost_ns = 50000, scheduler calls
That's 50us...
In fact default value is 500000 = 500us not 50000 = 50us
But still, whatever value you pink: 1) it is not considering the caches geometry on a specific target 2) how much hot a task is really depends also on the specific task
So, what Leo is proposing (i.e. to set this value to 0), it seems to me more a specific optimization for a specific platform.
can_migrate_task() to check if tasks are cache hot or not and it compares sched_migration_cost_ns to avoid migrate tasks frequently.
This introduces side effects to easily pack tasks on the same one CPU and introduce latency to spread tasks within multi-cores, especially if we think energy aware scheduling is easily to pack tasks on single CPU. So after task packing on one CPU with high utilization, we can easily spread out tasks after we set sched_migration_cost_ns to 0.
... dunno how exactly this metric is used by the scheduler but, according to its name and you explanation, it seems that in the use-case you are targeting, tasks needs to me migrated more often than 50us. Is that the case?
main advantage is that there are sysfs entry for that so it can be tuned for each platform
Right, thus what we should better report in the documentation IMHO is eventually a recipe to find a suitable value for a specific platforms.
Which is a more generic solution, although still a suboptimal one since we are not considering the specific nature of tasks.
As a general comment, I can understand that an hardcoded 50us value could be not generic at all, however: is there any indication on how to properly dimension this value for a specific target?
Maybe a specific set of synthetics experiments can be used to figure out what is the best value to be used. In that case we should probably report in the documentation how to measure and tune experimentally this value instead of just changing an hardcoded value with another one.
Method 2: set busy_factor to 1:
This decreases load balance inteval time, so it will give more chance for active load balance for migration running task from little core to big core.
Same reasoning as before, how can be sure that the value you are proposing (ie. busy_factor=1) it is really generic enough?
Method 1 can improve prominent performance on one big.LITTLE system (which has CA53x4 + CA72x4 cores), from the Geekbench testing result the score can improve performance ~5%.
Tested method 1 with Geekbench on the ARM Juno R2 board for multi-thread case, the score can be improved from 2348 to 2368, so can improve performance ~0.84%.
Am I correct on assuming that potentially different values can give us even better performance but we tried and tested only the two values you are proposing?
For the 1st test, the root cause was that tasks was hot on a CPU and can't be selected to migrate on other CPU because of its hotness so decreasing the sched_migration_cost_ns directly reduce the hotness period during which a task can't migrate on another CPU
Ok, I don't know how exactly this value is impacting on load balancing but, still, what Leo is proposing is to reduce the value from 50us to 0su.... even if the original value should be 500us: does Geekbenck tasks needs to migrate more often than 500us?
If I'm not wrong 500us is quite likely lower than sched_min_granularity_ns (2.25 ms on my Nexus 5X).
Sorry for my lake of knowledge on that code but I would really like to know what are the real reasons for the speedup we get by completely disregarding the migration costs.
Maybe Geekbench is an heavily CPU bounded task with a small working set?
If that's the case, what's the impact of using 0 for sched_min_granularity_ns on tasks which have a bigger working set?
That being said, i'm not sure that this should be put in the Documentation/scheduler/sched-energy.tx
I agree with Vincent on that.
Moreover, do we have any measure of the impact on energy consumption for the proposed value?
Tested method 2 on Juno as well, but it has very minor performance boosting.
That seems to support the idea that what you are proposing are values "optimal" only for performance on a specific platform. Isn't it?
Signed-off-by: Leo Yan leo.yan@linaro.org
Documentation/scheduler/sched-energy.txt | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+)
diff --git a/Documentation/scheduler/sched-energy.txt b/Documentation/scheduler/sched-energy.txt index dab2f90..c0e62fe 100644 --- a/Documentation/scheduler/sched-energy.txt +++ b/Documentation/scheduler/sched-energy.txt @@ -360,3 +360,27 @@ of the cpu from idle/busy power of the shared resources. The cpu can be tricked into different per-cpu idle states by disabling the other states. Based on various combinations of measurements with specific cpus busy and disabling idle-states it is possible to extrapolate the idle-state power.
+Performance tunning method +==========================
+Below setting may impact heavily for performance tunning:
+echo 0 > /proc/sys/kernel/sched_migration_cost_ns
+After set sched_migration_cost_ns to 0, it is helpful to spread tasks within +the big cluster. Otherwise when scheduler executes load balance, it calls +can_migrate_task() to check if tasks are cache hot or not and it compares +sched_migration_cost_ns to avoid migrate tasks frequently. This introduce side +effect to easily pack tasks on the same one CPU and introduce latency to +spread tasks within multi-cores, especially if we think about energy awared +scheduling to pack tasks on single CPU.
+echo 1 > /proc/sys/kernel/sched_domain/cpuX/domain0/busy_factor +echo 1 > /proc/sys/kernel/sched_domain/cpuX/domain1/busy_factor
+After set busy_factor to 1, it decreases load balance inteval time. So if we +take min_interval = 8, that means we permit the load balance interval = +busy_factor * min_interval = 8ms. So this will shorten task migration latency, +especially if we want to migrate a running task from little core to big core
+to trigger active load balance.
1.9.1
-- #include <best/regards.h>
Patrick Bellasi
-- #include <best/regards.h>
Patrick Bellasi