In association with heise online

ACPI, PCI and power management

The cpuidle code now logs a processor's recent idle phases and tries to detect repetitive patterns – such as repeatedly waking up shortly after going into standby. The code uses this data to make a more informed decision about whether and how deeply to put the processor into standby in the next idle phase. The ondemand governor of the cpufreq code now regards the time some processors spend waiting for the completion of I/O tasks as normal CPU loads, unless configured differently. These two changes are to considerably increase the data throughput with partial system loads on some systems, because the kernel previously used the CPU power saving modes too aggressively with some systems and access patterns. Ingo Molnar in his Git-Pull request for the changes to the process scheduler explained that as a result, the time required by the CPU to go to sleep or wake up substantially slowed down the data flow.

The kernel now includes the experimental intel_idle driver, which directly controls various power saving mechanisms of Intel CPUs instead of leaving this task to a sometimes badly programmed ACPI BIOS – background information on this can be found in the commit comment as well as an article on Kernel version 2.6.35 will support the APEI (ACPI Platform Error Interface) and Error Record Serialisation Table (ERST) described in the ACPI 4.0 specification (for instance 1, 2, 3, 4, 5, 6, documentation). These interfaces allow the hardware to inform the operating system of hardware issues such as chip-set or memory problems.

About the source code management system

Many of the links in this article point to the relevant commits in the web front end of Linus Torvalds' Git source code management system for Linux, because these commits tend to contain a lot more information about the respective changes. The commit comment in the mid section of the web page displayed by the Git web front end is often a particularly helpful source of further information. This is where the author of a patch usually describes the background and intended effects of the changes.

The bottom section of the Git web front end lists the files that are affected by the patch. The "diff" link behind each file name shows how the patch modifies the respective file; if you want to view the complete patch in its raw form, click on the commitdiff link. Even if you don't have any programming skills the patches are often a good source of information, because they also contain changes to the documentation and comments within the code.

Architecture code and Memory subsystem

Various memory compaction options (core, tunable configuration as well as triggers for Proc and Sysfs) allow the kernel to de-fragment the working memory to create large, coherent areas of free memory if required. Modern CPUs with large memory pages (for instance 2-MByte pages instead of 4-KByte pages) can use such areas to reduce the processor's management overhead, which improves performance especially in the fields of virtualisation and large databases. Further background information about the memory de-fragmentation function can be found in in an article on

Linux 2.6.35 also fully supports a feature called Turbo Core that allows some of the six-core processors AMD introduced several weeks ago to increase the frequency of individual cores when at least three of the cores are sleeping. Procfs enables users to detect the existence of Turbo Core CPUs; the frequency enhancement feature can be disabled via Sysfs if required. These measures will soon conclude the saga about Turbo Core performance issues, after stable kernel versions, and 2.6.34 already introduced corrections which at least allowed AMD's six-core processors to reach nominal speeds.

Next: Virtualisation & Drivers

Print Version | Permalink:
  • Twitter
  • Facebook
  • submit to slashdot
  • StumbleUpon
  • submit to reddit

  • July's Community Calendar

The H Open

The H Security

The H Developer

The H Internet Toolkit