OnQ Blog

Developers: Balancing performance and power consumption with big.LITTLE

Mobile application development requires a careful balance of power consumption and CPU performance while operating within specific thermal constraints. In our previous blog on big.LITTLE, we talked about how the big.LITTLE architecture can help developers achieve this balance. In this blog we’ll delve a little deeper into what happens behind the scenes with some strategies for programming on a big.LITTLE platform.

Balancing big and small tasks

Optimal application performance on big.LITTLE takes place at the hardware level, but may be done in conjunction with the OS. In order to achieve this, many platform API’s include abstractions that developers use to provide “hints” to the system on how they would like the platform to control power consumption and performance. We’ll talk a bit more about this later in the blog, but first, it’s important to understand a bit about what you’re trying to accomplish and to develop some general strategies around those goals.

In mobile application development, you want your application to meet power consumption requirements first, and then optimize processing performance within that power budget. For the most part, try to use the API to influence the platform and use the small cores as much as possible. Use the big cores only if necessary since big cores consume more power. As workloads commonly occur in bursts on mobile, big cores should ideally be employed only for short time periods and for “big” tasks. Which of course begs the question, what exactly is a “big” task?

Categorizing tasks as “big” or “small” can be done in a variety of ways such as averaging CPU workloads across timeframes (e.g., 1ms windows), setting a CPU workload threshold above which a task is considered “big”, and/or classifying all shorter execution times for periodic tasks as “small”. In some cases, you may need to use profiling tools during development to help in identifying this. Note too that some tasks can switch between big or small over time based on such heuristics, so you’ll need to find the optimal balance.

Another area to watch for is excessive or unnecessary wakeups of idle cores, which can result in more power consumption. One solution is to pack tasks onto the same core while trying to not overload a core. Thankfully runtimes for big.LITTLE platforms, such as those in our Qualcomm Snapdragon mobile platforms, are engineered to employ three common task scheduling methods to help take care of such issues for you:

  • Core Clustering: cores of the same size are treated as one cluster, and then the most appropriate cluster is chosen based on system demands. This can be efficient if the whole cluster is migrated to the big core. However, this is less optimal than the following two methods, because the CPU frequency driver tells the OS kernel the required frequency and voltage.
  • In-kernel switching (aka CPU migration): a big and a little core are paired into a virtual core in which only one of the two physical cores in that virtual core is used, depending on demands. This provides increased efficiency over Core Clustering, but requires that the capabilities of the cores (e.g., a big and little core) are the same.
  • Global task scheduling: all physical cores are available all of the time, and the global task scheduler allocates tasks on a per-core basis depending on demands. This is the optimal method because the OS scheduler can allocate work on any core, all cores, or any combination, while unused cores are automatically turned off. In addition, this method doesn’t require matching core configurations. It can react more quickly to load changes, and the work can be allocated at a finer level of granularity than by the CPU frequency driver used in Core Clustering.

How to optimize your development

Optimization was once something you did at the end of the project to make things run faster. But with today’s multi-core processors, optimization is something you should plan for and implement right from the start of your project. From an API standpoint, you’ll need to identify and understand all of the abstractions provided in the API for a given platform.

One type of abstraction is a “mode” which can be set programmatically based on known performance requirements or dynamically at runtime. For example, our Snapdragon Power Optimization SDK is designed to support five “static” power modes that developers can select from:

  • Efficient mode: achieves close-to-best performance with power savings.
  • Performance burst mode: supports all cores at the maximum frequency for a short duration of time. Useful for bursts of intensive computation to gain performance.
  • Saver mode: provides around half of the peak performance of the system and helps when the performance requirements of the application are small.
  • Window mode: allows for fine tuning of performance/power balance using arguments to set the minimum and maximum frequency percentages relative to the maximum frequency that cores can use.
  • Normal mode: returns the system to its default state.

Another common abstraction is a construct called a “task”. This is a container for work to be performed that takes care of threading and parallelization details. For example, our Qualcomm Snapdragon Heterogenous Compute SDK represents units of work in tasks and provides supporting APIs to manage dependencies and synchronization. Tasks can also be created for different types of processors including the CPU and GPU. These and the other facilities provided by the API can provide a rich set of controls for balancing performance and power consumption.

The implications of big.LITTLE

Knowing how big.LITTLE works and devising a strategy to balance power consumption and performance requirements is the first step towards optimizing your application on mobile. Once that is established, developing a clear understanding of the abstractions provided by your platform’s API will allow you to carry out your strategy and give the best possible chance to meet your power and performance targets.

Check out the different tools and resources available within Qualcomm Developer Network, and learn more how developing for big.LITTLE platforms can enhance development in your next mobile project. You can also access our forums for additional information.


Qualcomm Snapdragon is a product of Qualcomm Technologies, Inc. and/or its subsidiaries.


Opinions expressed in the content posted here are the personal opinions of the original authors, and do not necessarily reflect those of Qualcomm Incorporated or its subsidiaries ("Qualcomm"). Qualcomm products mentioned within this post are offered by Qualcomm Technologies, Inc. and/or its subsidiaries. The content is provided for informational purposes only and is not meant to be an endorsement or representation by Qualcomm or any other party. This site may also provide links or references to non-Qualcomm sites and resources. Qualcomm makes no representations, warranties, or other commitments whatsoever about any non-Qualcomm sites or third-party resources that may be referenced, accessible from, or linked to this site.