Kernel Summit 2006: The CPU panel

2006 Kernel Summit coverage on LWN.net.

For some years, the Kernel Summit has included a panel session where processor architects from a number of vendors could talk about their plans and listen to the developers' concerns. Intel's Stephen Fisher started the discussion with an overview of upcoming processor designs. The processor roadmap included a number of process and design improvements, mostly aimed at improving performance, instruction flow, and power management. There were a lot of low-level hints on how to improve performance on Intel processors; many of them would probably be more useful to compiler writers.

The IA-64 (Itanium) architecture was never mentioned.

AMD's Rich Brunner is a long time Kernel Summit regular. From his presentation, AMD is working hard at consolidating its position in the high-end enterprise market. It's not everybody who needs features like 1GB pages, 48-bit physical addresses, and quad-core packages. Virtualization remains high on AMD's agenda; neither of the other two presenters mentioned it. AMD is also pushing forward on power management, with features like allowing each CPU on a shared core to be running at a different power level. He also took the opportunity to let the Summit attendees know that AMD is looking for Linux kernel hackers.

Freescale Semiconductor was represented by Kate Stewart. Freescale offers processors based on a number of "IP blocks," with various architectures. They are mostly working in the embedded market, and would like to see kernel support for features aimed at that market; these include asynchronous cryptographic operations, hardware network acceleration, and faster boot times.

There didn't seem to be a whole lot on the developers' minds during the general discussion; the coffee, perhaps, had yet to take full effect. There was some talk of machine check exceptions, which seem to be an increasing concern as chip features get smaller and faster. There is much need for improved machine check support which allows the kernel to assess and contain the damage when something goes wrong. If it is possible to determine that only a single process is compromised, it is much nicer to kill that process than to panic the entire system.

Another issue is prefetching of data. Highly optimized code will often include explicit prefetch instructions, added in the hope of improving performance by having data in the cache by the time it is needed. Processors are getting smarter (and more aggressive) about doing their own prefetching, however, to the point that manually-added prefetches might actually make things run more slowly. AMD already has a processor mode which causes it to avoid explicit prefetch commands; Intel may soon follow.

• Next: Mini-summit summaries.

---

to post comments