Linux Kernel News - December 2013

Mainline Release (Linus's tree) News

The last 3.13 release candidate for 2013 came out on December 29th. This 3.13-rc6 is small with just 81 commits to infiniband, gpu, cpufreq, libata, and block drivers in addition to a few small filesystem fixes, and ARM SoC related changes. Please read the 3.13-rc6 release announcement.

Right before Christmas on December 22nd, 3.13-rc5 came out. Changes in this rc include drivers, architecture, filesystems, scheduler, and mm (numa) fixes. One important news in this release announcement is about the 3.14 merge window will start after Linus Torvalds gets back from attending the Linux Conference in Australia. Please find the full text for the 3.13-rc5 release announcement.

3.13-rc4 came out on December 15th and it includes networking and gpu driver changes in addition to usb, input, and media. Please find the 3.13-rc4 release announcement.

3.13-rc3 was released on December 6th. This release candidate includes changes to drivers, net, scsi, sound, crypto being the notable ones, and ARM DT. Please read the 3.13-rc3 release announcement.

Stable release News

As of this writing the latest stable releases are as follows:

ReleaseVersionProjected EOL
Stable announced
Stable November 29 2013
Longterm 2015
Longterm 2014
Longterm October 22 2013
Longterm 2.6.342.6.34.14 mid-2013
Longterm 2.6.322.6.32.61 mid-2014
Extended stable 3.11.y.z3.11.10.2Extended Stable
Extended stable 3.8.y.z3.8.13.15Extended Stable
Extended stable 3.5.y.z3.5.7.28Extended Stable

If you ever wondered how these stable releases are managed and how often a new release comes out, here is more detail: Active kernel releases

Linux RT

Linux RT stable releases_ are numerous. Please checkout linux-stable-rt.git for their latest versions.

Where can you find all git trees for Linux releases?

Linux ReleaseGit
Stable releases (all)git://
Linux RT releasesgit://
Extended stable releasesgit://
Bleeding edge linux-nextgit://

3.14 content?

There are a few things already in the pipeline for the 3.14 merge window. bcache fixes and enhancements, and Arasan's SDHCI driver are the ones that caught my attention.

Energy-aware scheduling use-cases and scheduler issues

Morten Rasmussen (ARM) sent out detailed description of use-cases, issues, and system topologies as a follow-up to the request from the scheduler maintainers at the Energy-aware Scheduling workshop at the 2013 Kernel Summit. These use-cases provide background for the need to improve energy awareness in the scheduler. This thread also includes list of problems that prevent the current scheduler from delivering good energy/performance balance in common use-cases. This balance is very important in conserving battery power and at the same time be responsive when user actions demand peak performance. These use-cases are Android focused to start with, however as the discussion continues, use-cases covering other areas of interest would hopefully emerge.

A scheduler that is unaware of power topology, frequency scaling, and heterogeneous cores would make sub-optimal task migration decisions that could result in bad performance as well as poor energy savings. Scheduling audio tasks on 3-cpus could consume more energy without measurable performance gains. It is possible to meet the audio performance needs on a single cpu instead and leave the other 2-cpus idle, provided the cpus can be power-gated individually. On the other hand, playing video using single cpu would require the cpu to be run at higher frequency which will consume more power than spreading the video tasks on multiple cpus running at lower frequencies. For a scheduler to make these decisions, it needs to understand the energy topology as well as task behavior.

In some cases, scheduling tasks on a cpu that is active is better for energy savings compared to the cost of bringing an idle cpu to a fully active state. If scheduler is made aware of cpu idle states, then it can assess how deep an idle state a cpu is in and estimate the cost of bringing that cpu to active state. Scheduling low intensity work-loads on faster cpus on heterogeneous systems could lead to higher energy costs. Heterogeneous systems in this context are the systems with different kinds of cpus i.e, a mix of A15s and A7s for example. If scheduler has this information, then it can make intelligent scheduling decisions that could lead to good energy/performance balance.

In general, it is energy efficient to avoid higher cpu frequencies and only run them when a work-load could benefit from running them at higher frequency. However, this rule can not be applied universally on all work-loads and platforms. It sounds complex, doesn't it? In addition to the complexities involved in predicting whether it is energy efficient to schedule tasks in a work-load on a single cpu or spread them out on multiple, there is the platform to platform variation to be concerned about. A work-load centric scheduler would not scale well on all platforms as the energy required to run cpus at higher frequencies is highly platform dependent.

The original thread was posted to the linux-pm mailing list and has been reposted to LKML to facilitate discussion with the larger Linux kernel developer community. Please find the discussion at Energy-aware scheduling use-cases and scheduler issues.

Linux Allwinner ARM SoCs upstream support?

The linux-sunxi community has been making steady progress towards adding support for Allwinner ARM open-hardware SoCs. There is a good chance that the bulk of the support will be in included in 3.14 or 3.15. There is also a parallel effort in adding support for these boards in Fedora 21+ kernels.

Upstream support for low-cost open-hardware boards will enable more developers and enthusiasts to get involved. Refer to the arch/arm/mach-sunxi for the source code and arch/arm/boot/dts for the device trees for various sunxi boards. For more information on the mainlining effort, please read Sunxi Linux Mainlining Effort.

DMAengine driver work is in progress as well as SPI, SDIO, SATA, and AXP209 drivers. AXP209 is the PMU (Power Management Unit) used by A10, A13, and A20 SoCs. More on the Fedora effort can be found in the following announcement: Supporting Allwinner ARM SoCs in Fedora 21+ kernels ....

Final Thoughts

The Energy-aware scheduling work is long overdue. Current scheduler is unable to meet the demands of diverse work-loads and fails to balance energy savings and performance on mobile devices. The hope is that 2014 will see some concrete discussion and move towards incorporating and/or enhancing the current scheduler with energy-aware features. All of this needs to be done in a way that doesn't break performance on common work-loads.

Next up is the rest of the 3.13 integration cycles and the release of 3.13 itself in about 2 weeks. 3.14 development is wrapping with the merge window right around the corner. Wishing you all a Happy and productive 2014. Keep those patches coming.

Load Disqus comments