Introduction

This article is meant to help people understand the steps involved in porting the IKS (In kernel Switcher) solution to their hardware and plan for such activity. The first part concentrates on the minimum areas to be addressed for a successful port. The next section looks at some of the interactive governor tuneables that need adjustment in order to attain the desired performance level.

For more details on what the IKS solution is please refer to this companion document or this LWN article.

Porting Guide

The topics below are presented in the order in which they are needed as the kernel is booting. It is strongly suggested to complement this information by studying the code that was written for the TC2 reference platform.

Enabling the IKS functionality

The IKS functionality is enabled by setting the CONFIG_BL_SWITCHER kernel flag to 'y'. From there the switcher (IKS) will be activated by default when the kernel boots.

At that point it is possible to switch between IKS and MP by passing 'bL_switcher_active=no' to the kernel on the boot command line or via SYSFS:

$ echo [0,1] > /sys/kernel/bL_switcher/active

Note that the above mechanism are for debugging purposes only. Linaro does not recommend nor support a system in production that would alternate between the two models.

The device tree

The layout of cluster and CPUs within those clusters must be detailed in the device tree source file. When the kernel starts this information is parsed and used during the initialisation of the SMP subsystem. Cluster and CPU nodes can be laid out as follow:

Multi Cluster Power Management

The multi cluster power management (MCPM) API is at the heart of both IKS and MP solutions. It includes a set of machine specific methods to perform low-level actions. Those methods form a platform specific backend that must be registered with the MCPM core. Note that a discussion on cluster management race avoidance is probably good to introduce before moving on to the next two sub sections. Documentation on the subject can be found in "Documentation/arm/cluster-pm-race-avoidance.txt" in the kernel repository.

Board Specific Backend

To keep the MCPM generic a platform specific API was introduced. That API (struct mcpm_platform_ops) is used to manage platform specific cluster and CPU power up and down operations. It is communicated to the MCPM by calling 'mcpm_platform_register()', something that needs to be done _before_ 'smp_init()' gets called.

The best way to do so is probably to use an 'early_initcall' as enacted in the TC2 implementation:

On the TC2 'vexpress_spc_check_loaded()' is the initialisation point for the serial power controller (SPC), a component that plays a crucial role in cluster and CPU management on that specific target. If the platform being ported to has a similar mechanism, this would be a perfect place to ensure that it is initialised properly.

By way of 'mcpm_sync_init', the MCPM API provides the functionality to install a very low level cluster management function to be called every time a cluster is powered up. Please refer to the TC2 implementation for more details on this.

It is very important to have a good understanding of the callback methods defined in 'struct mcpm_platform_ops'. For that purpose the following summary should be complemented with a careful reading of 'mcpm_entry.h' where 'struct mcpm_platform_ops' is defined and examples in 'tc2_pm.c' and 'dcscb.c':

power_up: Powers up a CPU on a given cluster. It is recommended to keep track of the CPU and clusters as they are powered up, something that should be done with concurrency in mind. Note that CCI management should also take place at this time.

power_down: Expected to take down the CPU on which the code is running on, including flushing the CPU's caches, switching off the CCI interface and snooping if needed. Once again concurrency should be considered when doing so.

suspend: Same as 'power_down' but set the re-entry point of the CPU before going down.

powered_up: Mainly to clean up the power up sequence and get ready for the next shut down but also to make sure the current cluster can't be switched off.

SMP operations

The MCPM API is wrapped in the 'mcpm_smp_ops' structure and can be found in 'arch/arm/common/mcpm_platsmp.c'. Said structure needs to be passed to 'smp_set_ops()', most likely as part of the initialisation function that is referenced by '.smp_init' in the machine declaration macro.

In the above 'vexpress_smp_init_ops()' is assigned to '.smp_init' in the machine description structure. From there 'vexpress_smp_init_ops' simply feeds 'mcpm_smp_ops' to 'smp_set_ops()' if the MCPI kernel configuration flag has been enabled:

The Clock Framework

The big.LITTLE solutions developed by Linaro are using a generic cpufreq driver that provides a very good foundation for device frequency scaling. If the target platform is to use this driver then a clock for each cluster must registered with the common clock API. Note that the generic cpufreq driver assumes that the clock for each cluster is named 'clusterX', where 'X' is the cluster number.

As an example the TC2 platform has 2 clusters and as such, the SPC initialisation code will register two clock with the common clock framework, i.e "cluster0" and "cluster1".

It is expected that the 'clk_ops' for each registered clock has the capability to set the frequency on the cluster they represent. Clocks are registered using 'clk_register()' and 'clk_register_clkdev()', the latter being specifically important for name lookup by the cpufreq driver.

The Generic Cpufreq driver

As mentioned above the IKS and MP projects have produced a generic cpufreq driver that provides a very good starting point for managing DVFS on a big.LITTLE implementation. The driver has a generic and a platform specific portion, with the generic part being enabled by switching on the ARM_BIG_LITTLE_CPUFREQ flag in the kernel config.

By itself the generic portion of the driver will not be registered with the cpufreq core. For that to happen a platform specific shin needs to be provided. The said shin should provide a platform specific instantiation of a 'struct cpufreq_arm_bL_ops' that will convey methods to manage the frequency table for each discovered cluster.

It is very important to keep in mind that a clock for each cluster needs to be registered with the common clock API for the generic big.LITTLE cpufreq driver to work properly.

Interactive Governor Tuneables

The IKS solutions can work with any governor and isn't specifically tied to the interactive governor. We decided to concentrate on the latter because of the targeted audience and the nature of the workbench used in the performance assessments. Note that tuneables for MP are not yet available due to ongoing development.

When tuning the IKS solution on a given platform it is important to get a reference point, a yard stick that gives an idea of how the system performs. Since there is two A15 processors on the TC2 we decided to that our reference system would run with only two A15 processors - with optimal settings it is clear that the system can _not_ yield better performance than with this configuration.

Background

Before hoping to get good performance out of IKS a system _must_ be proven to perform optimally when using only the A15 cores.

Most of the software performance gained from a big.LITTLE architecture comes from how the cpufreq governors are tuned. In our dealings with the interactive governor we concentrated on the following 6 tuneables:

go_hispeed_load: CPU load at which the frequency should jump to 'hispeed_freq'.

above_hispeed_delay: when running above 'hispeed_freq', amount of time to spend at one frequency before moving up to the next one (in usec).

timer_rate: frequency at which the cpu speed is verified to see if an adjustment is needed (in usec).

min_sample_time: amount of time that must be spent at a given frequency before moving down to the next one (in usec).

target_loads: An example is probably best for this one:

85 600000:90 1000000:97

The above indicate that for all frequencies below 600MHZ the target load should be 85%, between 600MHz and _below_ 1GHz the target load should be at 90% and for 1GHz and above, 97%.

TC2 settings

target_loads: "85 1000000:97": Targeting a CPU load average of 85% up until 1GHz where the load average needs to be at 97%.

go_hispeed_load: 90%

hispeed_freq: 500MHz

above_hispeed_delay: 5000 usec

timer_rate: 10000 usec

The above settings allowed IKS on the TC2 implementation to reach a 60/90 ratio, that is 90% of the performance yielded by an A15 solution, using 60% of the power. That performance ratio was obtained when running the bbench application with audio playing in the background - it is expected that other scenarios will yield different performance metrics. It cannot be stressed enough that the same settings will very likely produce varying results on a different platform.