The sched_mc feature has been originally designed to improve power consumption of multi-package system and several architecture functions are available to tune the topology and the scheduler's parameters when scheduler rebuilds the sched_domain hierarchy (change the sched_mc_power_savings level). This patches improve the power consumption of dual and quad cortex-A9 when the sched_mc_power_savings is set to 2. The following patches' policy is to accept up to 4 threads (can be configured) in the run queue of a core before starting to load balance if cpu runs at low frequencies but to accept only 1 thread for high frequencies, which is the normal behaviour. The goal is to use only one core in light load situation and all cores in heavy load situation
Patches [1-2] modify the ARM cpu topology according to sched_mc_power_savings value and Cortex id. Patch [3] enables ARCH_POWER feature of the scheduler. Patch [4] adds arch_scale_freq_power function for ARM platform. Patches [5-6] modify the cpu_power of CA-9 according to sched_mc_power_savings' level and core frequency. The main goal is to increase the capacity of a core when using low cpu frequency in order to pull tasks on this core. Note that this behaviour is not really advised but it can be seen as an intermediate step between the use of cpu hotplug (which is not a power saving feature) and a new load balancer which will take into account low load situation on dual core. Patch [7] ensures that cpu0 is used in priority when only one CPU is running. Patch [8] adds some debugfs interface for test purpose. Patch [9] ensures that the cpu_power will be updated periodically. TODO list: -remove useless start of ilb when the core has capacity. -add a method (DT, sysfs, ...) to set threshold for using 1 or all cpus for CA-9 v2: *Modify the method to update cpu_power *There are fewer patches than v1 because some issues are fixed by patches that has been pushed for 3.2. *These patches has been tested on snowball and vexpress boards. *Performance results are similar to v1 v1: http://permalink.gmane.org/gmane.linux.linaro.devel/8087 Vincent _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
