The 2012 Kernel Summit

By Michael Kerrisk and Jake Edge
August 29, 2012

The 2012 Kernel Summit was held in San Diego, CA, USA, over three days, 27-29 August. As with the 2011 Kernel Summit in Prague (and following on from discussions at the 2010 Kernel Summit), the 2012 summit followed a different format from the ten previous summits. For 2012, the event took the form of an invitation-only plenary-session day followed by two days of minisummits and additional technical sessions shared with the co-located 2012 Linux Plumbers Conference that kicked off on 29 August; the agenda for days 1 and 3 can be found here. (The ARM minisummit was something of an exception to this format: it ran for two days, starting on the same day as the plenary sessions.)

Main summit, day 1

The first day of the Kernel Summit, on 27 August, consisted of plenary sessions attended by around 80 invitees. Among the topics were the following:

The future of kernel regression tracking; the kernel development community is in strong agreement on the value of regression tracking, and is currently looking for some person(s) to take up this high-profile work.
Supporting old/oddball architectures, tool chains, and devices: how long must we support ancient hardware and software, and how do we leave it behind?
Regression testing; how can we do a better job of finding bugs before they bite users?
Distributions and upstream; what can kernel developers do to make life easier for their main customers — the distributors?
Lightning talks: quick sessions on RCU callbacks and Smatch.
Kernel build and boot testing; a new framework for quickly finding regressions.
Android upstreaming: the ongoing process of getting the Android kernel code into the mainline.
Improving the maintainer model; do our subsystem maintainers scale?
Stable kernel management; how is the stable process working?
Tracing and debugging, and how to get better oops output in particular.
Linux-next and related improvements to the development process.

Main summit, day 2

The memcg/mm minisummit covering a wide range of topics related to memory management.

Main summit, day 3

Module signing; toward a way to finally get this feature into the kernel.
Kernel summit feedback; how did the event work out this year, and what changes should be made for future years?

ARM minisummit, day 1

The first day of this year's Kernel Summit coincided with day one of the ARM minisummit. Given that the "minisummit" spanned two days, there was talk of false advertising, but there was lots to cover.

Secure monitor API: how best to support the secure monitor mode across a wide variety of processors.
Stale platform deprecation: some ARM platform support has clearly not been used for years; how do we clean out the cruft?
Virtualization is coming to ARM, but brings some issues of its own.
DMA mapping has seen a lot of work in the last year, but there is still a fair amount to be done.

ARM minisummit, day 2

Process review for the arm-soc tree: how well is this tree working toward the goal of cleaning up the ARM architecture code?
Toward a single kernel image: what needs to be done to get a single kernel that boots on multiple ARM processor families?
AArch64: the current status of 64-bit support for the ARM architecture.
A big.LITTLE update; how can the kernel support this novel architecture?
DMA issues and how to best support generic DMA engines in particular.

Linux Security Summit

Secure Boot: keynote from Matthew Garrett.
Secure Linux containers: using SELinux to create sandboxed containers.
Integrity for directories and special files: extending the Integrity Measurement Architecture (IMA) to handle directories and other special files.
DNSSEC: a look at the "cryptographically secured globally distributed database" for domain names and more.
Security modules and RPM: expanding the hooks in RPM to support Smack and other security technologies.
Kernel security subsystem reports: reports from subsystem maintainers.

Notes from others

PCI minisummit, notes posted by Bjorn Helgaas.
ARM minisummit, posted by Will Deacon.
Media workshop notes, part 1 by Mauro Carvalho Chehab.
The realtime microconference from LPC, courtesy of Darren Hart.

Acknowledgments

Michael would like to thank the Linux Foundation for supporting his travel to San Diego for this event; Jake would like to thank LWN subscribers for the same.

Index entries for this article
Kernel	Kernel Summit
Conference	Kernel Summit/2012

to post comments

The 2012 Kernel Summit

Posted Aug 31, 2012 8:34 UTC (Fri) by felixfix (subscriber, #242) [Link]

This subscriber would like to thank Jake for going and writing about it, and hopes some of the money was spent on pizza and beer or whatever toots his horn.

This subscriber would also like to thank our Grumpy Editor for hiring Jake in the second place, and for running LWN in the first place.

This subscriber would also like to thank all the other subscribers, especially those who are at a higher (more expensive) level, for goading me to revise my budget when the opportunity presents itself.

The 2012 Kernel Summit

Posted Sep 4, 2012 1:43 UTC (Tue) by Baylink (guest, #755) [Link] (9 responses)

Concerning "cleaning up cruft in the ARM tree", note that this very issue is biting Raspberry Pi users on the ass; was it Debian that dumped ARM6 support?

The 2012 Kernel Summit

Posted Sep 4, 2012 8:14 UTC (Tue) by viiru (subscriber, #53129) [Link] (7 responses)

> Concerning "cleaning up cruft in the ARM tree", note that this very issue
> is biting Raspberry Pi users on the ass; was it Debian that dumped ARM6
> support?

No, it was not. The Debian armel port is still at armv5. IIRC Fedora and Ubuntu however only support v7.

I think someone had a special Raspberry Pi Debian port for v6 hard float. I think some people are also working on a Debian armv7 hard float port that aims for official inclusion (but doesn't aim to replace the current v5 soft float port).

The 2012 Kernel Summit

Posted Sep 4, 2012 11:38 UTC (Tue) by Jonno (guest, #49613) [Link] (6 responses)

Actually, Debian armel port is for armv4 soft-float, while the Ubuntu armel port is for armv7 soft-float.

Recently, both Debian 7.0 (wheezy) and Ubuntu 12.04 (precise) also added an armhf port for armv7 hard-float.

As the Debian armhf port don't work on the armv6 in the Raspbery Pi, while the armel port is much slower than necessary due to it's use of soft-float, Raspbian has released an armhf port for armv6 hard-float, which is forward compatible with the Debian armhf port (eg you can mix Raspbian armhf and Debian armhf packages on the same system, but that will obviously only work on armv7 hardware).

The 2012 Kernel Summit

Posted Sep 10, 2012 17:51 UTC (Mon) by BenHutchings (subscriber, #37955) [Link] (5 responses)

...while the armel port is much slower than necessary due to it's use of soft-float...

[citation needed] What I hear is that is that the performance hit is really marginal for almost all applications.

The 2012 Kernel Summit

Posted Sep 10, 2012 19:48 UTC (Mon) by Jonno (guest, #49613) [Link] (4 responses)

> [citation needed] What I hear is that is that the performance hit is really marginal for almost all applications.

http://www.memetic.org/raspbian-benchmarking-armel-vs-armhf
Shows a 5-40% improvement or most applications. Not all the difference is due to hardfloat, some is due to using an armv6, rather than armv4, instruction set, but still very relevant to the choice between Debian armel and Raspbian armhf for the Raspberry Pi.

https://wiki.linaro.org/OfficeofCTO/HardFloat/Benchmarks2...
A more "fair" set of armv7 vs armv7 benchmarks showing up to 1400% improvement, though indeed most applications are within the margin of error. The most interesting gains are IMHO in the ffmpeg and gtk benchmarks.

The 2012 Kernel Summit

Posted Sep 11, 2012 3:20 UTC (Tue) by BenHutchings (subscriber, #37955) [Link] (3 responses)

http://www.memetic.org/raspbian-benchmarking-armel-vs-armhf
Shows a 5-40% improvement or most applications.

I think I wasn't very clear. It is certainly possible to build significantly faster binaries for the RPi processor than are currently available in the armel architecture. But how much of the performance improvement is due to using the hard-float vs soft-float ABI and how much is due to optimising for v6 vs v4? You see, it should be possible to build optimised libraries for v6 processors and then use the dynamic linker's CPU feature checks to select between the v4-compatible and optimised v6 builds (like we do on i386 for libraries that benefit from use of CMOV and SSE2). And those could be added to Debian without any need to fork or rebuild. Has that been tried and compared?

https://wiki.linaro.org/OfficeofCTO/HardFloat/Benchmarks2...
A more "fair" set of armv7 vs armv7 benchmarks showing up to 1400% improvement, though indeed most applications are within the margin of error. The most interesting gains are IMHO in the ffmpeg and gtk benchmarks.

I can't help wondering whether the huge gains for two POVray tests (not seen in the Phoronix benchmarks that use POVray) are due to some mistake in building them (e.g. building without using the FPU at all). Also tests on a v7 core aren't necessarily representative of the RPi's v6 core. But this is hopefully somewhat indicative of the difference between hard-float and soft-float, and the results really are quite mixed!

The 2012 Kernel Summit

Posted Sep 11, 2012 3:34 UTC (Tue) by dlang (guest, #313) [Link] (2 responses)

> e.g. building without using the FPU at all)

Isn't that what softfloat vs hardflat is? softfloat is software floating point (i.e. no FPU) while hardfloat is using the hardware floating point engine (i.e., use the FPU)

The 2012 Kernel Summit

Posted Sep 11, 2012 5:23 UTC (Tue) by BenHutchings (subscriber, #37955) [Link]

Isn't that what softfloat vs hardflat is? softfloat is software floating point (i.e. no FPU) while hardfloat is using the hardware floating point engine (i.e., use the FPU)

Not if you're referring to the ABIs, which are the fundamental difference between what dpkg calls armel and armhf. The soft-float variant of ARM EABI (armel) requires that FP parameters and return values are passed in integer registers, for compatibility with FPU-less processors. Functions built for the soft-float ABI may still use an FPU if present, but they have to move values between integer and FP registers at call boundaries. The benefit of the hard-float ABI (armhf) in terms of code generation is that it uses the FP registers for parameters and return values, reducing the need for register moves.

Of course, targetting armhf does mean all code can be built to assume an FPU is present, without the need to provide a fallback for less capable processors. This is simpler in some ways as there is no need to do run-time CPU checks in executables, and no need to build multiple variants of libraries. But looking at this from a higher level again, adding optimised libaries to Debian's armel should mean less work in the long term for Raspbian...

The 2012 Kernel Summit

Posted Sep 11, 2012 8:21 UTC (Tue) by Jonno (guest, #49613) [Link]

The biggest difference between armhf and armel is that what an armhf compiler would have compiled into a single floating point instruction, an armel compiler will instead make into a function call.

On a floating point capable system that function will only be three instructions long (copy the arguments from integer registers to floating point registers, the actual floating point instruction, copy the result from a floating point register to an integer register), while on other systems the function will contain a complex emulation instead.

Thus, even armel will make use of the floating point capabilities of a processor that has one, but it will do so in an inefficient manner (for every instruction, add a function call and two register copies).

If a single user function contains many floating point operations, it is possible to minimize this cost by compiling two versions of it for armel, one that internally uses floating point instructions directly, and one that internally uses the standard emulation functions. That way you only have to pay the extra cost when crossing user-function-borders, rather than for every instruction. This can either be done on a function-by-function basis by the application developer, or on a library-by-library basis by the distributor (which is what Ben refers to). Adding such an alternative library for every fp-using library in Debian would have netted almost as large a benefit as that of Raspbian, without the need of forking the entire distribution, but I wouldn't want the job of trying to convince ~100 package maintainers and the release team that it was a worthwhile feature to add to wheezy in the middle of the pre-release freeze...

The 2012 Kernel Summit

Posted Sep 5, 2012 13:15 UTC (Wed) by arnd (subscriber, #8866) [Link]

There is no support for the chip used in the Raspberry Pi in the upstream kernel, so it can't possibly get any worse for them.

Regarding ARM architecture level support, we actually just removed most of ARMv3, so if you are running a RiscPC with an ARM610 or ARM710 CPU, you now have to upgrade to an ARMv4 based StrongARM CPU. It will probably be a number of years before anyone can seriously suggest removing ARMv4 or even ARMv5 support.