< Wednesday >

08:15 - 09:15 PDT [PLENARY]
Nautilus Foyer
09:15 - 09:40 PDT [PLENARY]
[Slides](http://www.linuxplumbersconf.org/2012/wp-content/uploads/2012/08/lpc2012-opening.pdf)
Nautilus 4/5
09:50 - 10:35 PDT
The adoption of UEFI is probably the biggest changes in the x86 world since the migration to 64-bit. While fundamentally a pile of code responsible for starting an operating system, UEFI provides features that reach all the way up to the running desktop. This gives us opportunities for tight integration between the OS and the firmware, providing a more cohesive experience for the user from the moment they turn their computer on. This presentation will provide a brief introduction to UEFI, followed by a discussion of the functionality it provides to the OS and the different parts of the Linux stack that can benefit from UEFI integration - for example, the combination of bootloader, kernel and graphics driver work that will allow us to move seamlessly from the firmware boot splash to a user login. Matthew Garrett does firmware integration work so you don't have to. He represents Red Hat on the UEFI Forum and is active in Linux UEFI development.

Participants:
attending e-bjarne-n (Bjarne Rosengren)
attending eblake (Eric Blake)
attending ezannoni (Elena Zannoni)
attending ezannoni-7 (LPC Submitter)
attending rsalveti (Ricardo Salveti)
attending srwarren (Stephen Warren)

Microconfs:
  • Presentations
Nautilus 1 Go to Blueprint
[Slides](http://www.linuxplumbersconf.org/2012/wp-content/uploads/2012/08/lpc2012-sched-timer-workqueue.pdf) === How to improve the selection of the target cpu in the timer and workqueue framework === It's sometime difficult to move a timer/hrtimer on a set of cpus in order to follow the load balance policy of the scheduler. We have some use cases where a timer, that is not specifically pinned to a particular cpu, stays on this cpu (or set of cpus) whereas all the tasks activity has moved on other ones. The timer/hrtimer frameworks currently call a scheduler function under some conditions but there is a limited number of use case where the timer will effectively migrate. The wokqueue framework doesn't have any link with the scheduler when it looks for a cpu on which it can run a work. The goal of this talk is to describe the potential issue and to discuss the possible solution. Topic Lead: Vincent Guittot Vincent Guittot is an embedded Linux engineer at ST-Ericsson. Since 2005, he has focused on mobile phone running Linux and Android. In 2010, he has joined the power management working group of Linaro. === Sharing information between scheduler and frameworks === The scheduler could take advantage of information from other frameworks, when it selects run queue for a task. These information are helpful not only for power consumption but also for performance by giving a mask of preferred CPUs. As an example, the wake up latency of a task is impacted by the C-states of the selected CPU. Choosing a CPU with a low C-state will reduce this latency. This talk will discuss the various inputs that could be shared with the scheduler Topic Lead: Vincent Guittot

Participants:
attending apm (Antti P Miettinen)
attending paulmck (Paul McKenney)
attending vincent-guittot (Vincent Guittot)

Microconfs:
  • Scheduler
Nautilus 2 Go to Blueprint

Microconfs:
  • Kernel Summit
Nautilus 3
Room Unavailable
Nautilus 4
Room Unavailable
Nautilus 5
10:45 - 11:30 PDT
The current CPU idle implementation in the Linux kernel is skewed towards per-CPU idle power management. Power consumption of components in the SOC that are part of a cluster of CPUs but do not belong to the CPU power domain is significant and should be managed in the CPU idle driver accordingly. Current ARM platforms manage cluster power states using ad-hoc code in the idle driver which results in code duplication that is not necessary and can be consolidated. Furthermore, CPU idle governors are not cluster-aware so that every low-power state decision is made on a per-CPU basis which turns out to be sub-optimal to achieve deep-sleep cluster states where all CPUs are required to be powered off to shut down additional cluster shared components like interrupt controllers and L2 shared caches. Considerable effort is taking place in the kernel community to improve this situation; in particular [coupled C-states](https://lkml.org/lkml/2012/3/14/363) provide a method to synchronize CPUs before entering cluster states and increase the cluster shutdown opportunities for a running SOC. This is a big step towards having a complete cluster aware CPU idle implementation but this does not yet provide a holistic solution. This talk will highlight the CPU idle requirements and intricacies of current and future ARM systems, inclusive of big.LITTLE multi-cluster SOCs and is aimed at Linux kernel Power Management developers. It is meant to kick-start the discussions on some topics (per-CPU idle states, CPU idle governors cluster awareness, cluster next event, coupled C-states usage) that should result in a hacking session implementing features required by a cluster aware CPU idle implementation. Lorenzo Pieralisi, ARM Ltd., Cambridge Lorenzo has worked at ARM Ltd since March 2010 as a Linux kernel developer. He obtained a Laurea degree (summa cum laude) in Microelectronics from the University of Ancona in March 2002. He carried out a PhD in Microelectronics at INP Grenoble where he defended his thesis in 2005 on on-chip interconnections for Advanced Computing. Prior to joining ARM, he worked at the AST (Advanced System Technology) Lab of STMicroelectronics in Grenoble France, where he spent 7 years programming kernel device drivers for ARM processors for a variety of purposes like power management, advanced computing and interconnect device drivers. He presented talks at DATE Europe in 2003, ICCD 2005, SoC conference in 2008, ELC Europe 2011 and other workshops around Europe. He is a keen and enthusiastic embedded systems programmer since the early days of microcontrollers and got involved with Linux kernel programming in 2006 for both personal interest and work. He is an active open source contributor. Amit Kucheria, working for Linaro as Canonical assignee Amit is a long-time Linux user and has worked on network QoS, wireless routing, power management in Linux at university, a California startup and finally Nokia where he led the power management team for a while. Lately, he's been working with the Linaro members to make Linux power management infrastructure more suitable for ARM SoCs. As Tech Lead of the Power Mangement Working Group, he gets to work with a diverse team in trying to standardize interfaces and tools for ARM power management. Daniel Lezcano, working Linaro as IBM LTC assignee Daniel worked in 1998 in the Space Industry and Air traffic management for distributed system project in life safety constraints. He acquired for this project a system programing expertise. He joined IBM in 2004 and since this date he does kernel hacking and pushed upstream the resource virtualization with the namespaces. In 2011, he joined the Linaro's Power Management Team and works on the kernel area, consolidating the cpuidle drivers across the different ARM SoC.

Participants:
attending apm (Antti P Miettinen)
attending lorenzo-pieralisi (Lorenzo Pieralisi)
attending paulmck (Paul McKenney)
attending srwarren (Stephen Warren)

Microconfs:
  • Presentations
Nautilus 1 Go to Blueprint
Not Attending The Core OS ( Core OS )
The term “Core OS” has recently been coined in an LWN article, describing the core (userspace) bits of an operating system. In this talk we want to give a quick overview of what we believe the Linux “Core OS” consists of technically, we want to draw the line where we believe the various projects belong in this (such as systemd, udev, dbus, …), and where they don’t, and where we want to go with this in the future. Topic Lead: Kay Sievers Topic Lead: Lennart Pottering

Participants:
attending e-bjarne-n (Bjarne Rosengren)
attending kaysievers (Kay Sievers)
attending kir-openvz (Kir Kolyshkin)
attending rsalveti (Ricardo Salveti)

Microconfs:
  • Core OS
Nautilus 2
Not Attending Mini-Summit Report Out ( Kernel Summit )

Microconfs:
  • Kernel Summit
Nautilus 3
Power Management Constraints Topics: 1) Power vs. Performance 2) Priority Based PM QoS Constraints Framework === Power vs Performance === In order to suffice problems related to a "minimum" quality of service for basic HW like CPU/networking/DMA, we have the existing PM QoS framework to solve our problems. As the discrete HW units grow on a SoC, so IMO should the PM QoS layer scale. The second part of the problem is the scaling "up" or "down". We can mirror the PM QoS constraints to Perf QoS constraints which would allow independent devices to scale the generic system upwards into the performance mode. The performance QoS can also be used by platform specific constraints like thermals to either throttle device/SoC features OR constraints like accelerated workloads that may require a minimal CPU/SoC operating point to scale SoC features. Examples include issue faced on memory throughput on TI platforms, increasing CPU frequency as discussed in mailing lists by NVidia developers, imposing constraints on devices like CPU/LCD for thermal management etc. Topic Lead: Sundar Iyer Worked/Working on PM/tunings/efficiency for Linux in ST-E/Intel === Priority Based PM QoS Constraints Framework === There are workloads that require certain CPU Freqs, these Workloads should be able to tell the system what Freq is the optimal freq. But there may be thermal constraints that should not be allowed to be breached which requires Freq throttling or a user may want to artificially throttle or bump up the Freq all these Freq constraint requirements becomes difficult to manage since now we have a problem of which of those to be selected. In order to solve this problem, we propose a priority based PM QoS for Freq Management. High Priority Constraints may be reserved for thermal Throttling, Medium for user throttling or bump up, and Low for process PM QoS constraints Topic Lead: Illyas Mansoor Illyas works in Power Management Domain in Intel, specifically contributed to Intel SoC Power Management Linux Kernel

Participants:
attending apm (Antti P Miettinen)
attending lorenzo-pieralisi (Lorenzo Pieralisi)
attending mark97229 (Mark Gross)

Microconfs:
  • Constraints
Nautilus 4 Go to Blueprint
Networking Topics 1. CoDel and FQ CoDel 2. Byte Queue Limits revisited === CoDel and FQ CoDel === Kathleen Nichols & Van Jacobson made a major work in the to help the bufferbloat problem that got some attraction these past years after Jim Gettys and Dave Taht communications. Here are the [result of this work](http://queue.acm.org/detail.cfm?id=2209336). Idea of Codel saying that buffers or large Queues are not bad per se (as BufferBloat could imply) Its the way Queues are handled that is critical. AQM are quite complex to deploy because RED (the most known AQM) is hard to tune and has some flaws. CoDel intent is to use the delay of packets in queue as the main input, and not the Queue length (in Bytes or Packets) It is designed to be a "No knob" AQM for routers. Its implementation uses a fairly simple algo intended for silicon integration. Since Kathleen and Van ideas were very close of the various ideas I had last year to improve linux AQM, I co-implemented Codel for linux (with Dave Taht). I also implemented fq_codel, which is SFQRED replacement, using Fair Queueing and CoDel managed per flow queue. I'll present various experimental results. Topic Lead: Eric Dumazet <email address hidden> Eric is currently working for Google. He is a linux networking guy, who did some work in packet schedulers lately: SFQ improvements, and CoDel / fq_codel implementations. === Byte Queue Limits revisited === [Slides](http://www.linuxplumbersconf.org/2012/wp-content/uploads/2012/08/bql_slide.pdf) Byte queue limits (BQL) is an algorithm to manage sizes of queues in network cards based on bytes, not on packets. The algorithm tries to estimate how many bytes the card is able to transmit, sizes the queue accordingly and accommodates to changing load. Properly sized (shorter) queues push queuing to upper layers of the stack, the queuing disciplines (qdisc), which reduces the time between a packet is scheduled for transmission and when it hits the wire. This reduces latency and allows better scheduling decisions in software. BQL is here for a year and it seems to work well given the lack of major complains. In this talk we are going to present experimental data on how BQL actually behaves and what are the effects of BQL buffer management for the rest of the stack. We are going to show that BQL does not need any knobs to selects a good size of the queues. We are also going to discuss and explain some limitations of the algorithm and some corner cases of its deployment due to its dependency on outer events that pace its execution. Topic Lead: Tomas Hruby Tomas is a PhD candidate at the Free University in Amsterdam in the Minix group of prof. Andy Tanenbaum and is exploring how to take advantage of multicore processors for designing reliable systems. He has been working on intrusion detection, filesystems and L4 microkernel. He is currently an intern in the Linux networking team at Google.

Participants:
attending therbert (Tom Herbert)

Microconfs:
  • Networking
Nautilus 5 Go to Blueprint
11:40 - 12:25 PDT
[Slides](http://www.linuxplumbersconf.org/2012/wp-content/uploads/2012/08/Adding-lock-elision-to-Linux.pdf) This talk introduces lock elision with hardware support, and describes a practical implementation in the Linux kernel and glibc. Lock elision is a technique to improve the parallelism of existing locks without changing the semantics. Using this allows to improve the scalability of both kernel and multi threaded user software. It describes the necessary changes to the kernel and to glibc, plus also some programming techniques to make best of use of elision. The audience is people interested in multithreaded programing and kernel programers. Andi Kleen is a long term contributor to the Linux kernel. His past kernel work including working on the x86-64 port, the linux network stack, and other areas. He currently focusses on Linux scalability. He works at the Intel Open Source Technology Center.

Participants:
attending eblake (Eric Blake)
attending paulmck (Paul McKenney)
attending sbahra (Samy Bahra)

Microconfs:
  • Presentations
Nautilus 1 Go to Blueprint
=== Exposing Routing to the Application Layer === In order to allow nicer configuration UIs and easier diagnostics it would be good if we could expose audio routing information to the application layer. === Representing DSPs in ASoC === As embedded systems continue to evolve, host-based processing is often offloaded to a co-processor dedicated for specific tasks in order to improve the performance and power utilization. In this the audio subsystem seems to be no exception and more vendors are trying to offload tasks to DSPs, be they embedded in SoCs or audio codecs. This evolution requires changes in ASoC to represent all the routing and processing capabilities of these DSPs. The current efforts are based on two methods being propagated. The first approach developed by Liam Girdwoodand TI, typically referred to as soc-dsp aka dynamic PCM, introduces the notion of dynamic PCM nodes, where audio front-ends (FEs-classic PCM device visible to user) and audio back-ends (BEs-soc-hardware interfaces) represent audio links. The second approach being discussed is referred as CODEC<-->CODEC model as proposed by Mark Brown, where the DSP is represented as another codec in the system and links to the real codec in the system through the machine map. This talk takes a look at both the approaches and latest evolutions, future plans on these methods and discusses the common infrastructure needs which need to considered for making this representation an effective one for SoC and codec vendors Topic Lead: Vinod Koul <email address hidden> Topic Lead: Pierre-louis Bossart <email address hidden>

Participants:
attending apm (Antti P Miettinen)
attending broonie (Mark Brown)
attending diwic (David Henningsson)
attending srwarren (Stephen Warren)
attending tiwai (Takashi Iwai)
attending vinod-koul (Vinod Koul)

Microconfs:
  • Audio
Nautilus 2 Go to Blueprint

Microconfs:
  • Kernel Summit
Nautilus 3
Three years ago at the inaugural Linux Plumbers Conference, we showed that a Linux OS should boot to the UI in 5 seconds or less. Since then, much has happened to take this from prototype to general deployed production technology. However, booting is only one of the operations for which the performance matters to users. The performance, and capabilities of the software update and associated tooling have an even bigger impact on the experience of the user than just booting in 2 seconds does. In this presentation I'll show what a 0.5 second software update looks like. However, since it'd boring to just show that you can be 300 times better than the yum tooling, I'll also show how what options this capability opens for those who develop operating systems to service their userbase better. The revealing of the code and project that showcase these capabilities will happen at the time of the LPC presentation. I'll likely will have a few other surprises ready by LPC as well; there's still time left between now and LPC. Topic Lead: Arjan van de Ven Arjan van de Ven is a Sr Principal Engineer at Intel's Open Source Technology Center, where he works on various things Linux, ranging from general kernel technology to power and performance tools and optimizations.

Participants:
attending eblake (Eric Blake)
attending kaysievers (Kay Sievers)
attending kir-openvz (Kir Kolyshkin)
attending rsalveti (Ricardo Salveti)

Microconfs:
  • Core OS
Nautilus 4 Go to Blueprint
Networking Topics: 1) Data Direct I/O 2) Ethernet Audio/Video Bridging === Data Direct I/O Significantly Boosts Networking Performance and Reduces Power === This presentation calls out the new Data Direct I/O (DDIO) platform technology that enables I/O data transfers that require far fewer trips to memory (nearly zero in the most optimal scenarios). In doing so, DDIO significantly boosts performance (higher throughput, lower CPU usage, and lower latency), and lowers power consumption. The updated architecture of the Intel Xeon processor to remove the inefficiencies of the classic model by enabling direct communication between Ethernet controllers and adapters and host processor cache. Eliminating the frequent visits to main memory present in the classic model reduces power consumption, provides greater I/O bandwidth scalability, and lowers latency. By avoiding the multiple reads from and writes to system memory, DDIO reduces latency, increases system I/O bandwidth, and reduces power consumption. Intel DDIO is enabled by default on all Intel Xeon processor E5 based servers and workstation platforms. This presentation will explain the technology in detail as well as how it currently gets used. Performance numbers will be included from our Ethernet controllers which will clearly show the benefits of the technology. All performance gains will be examined and explained including the power reduction while increasing the bandwidth as well as reducing latency. === Ethernet Audio/Video Bridging (AVB) - a Proof-of-Concept === Using our latest gigabit Ethernet controller we designed and implemented a Proof-of-Concept Audio Video Bridging device using the IEEE 802.1Qav standard. The project was implemented using a modified Linux igb driver with a user space component to pass the AVB frames to the controller while in addition maintaining normal network connection. This presentation will go through the details of the project, explain the challenges and have a demo of the working implementation at the end. AVB is now being used to pass audio and video to many different types of A/V devices using Ethernet cables instead of having to run large heavy analog A/V cables to the devices. So not only is all the analog cabling gone but the performance is also far superior with the ease of controlling all the audio and video from a single work-station. Topic Lead: John Ronciak John is a SW Architect working for Intel in the LAN Access Division (LAD). John has 30 years experience writing devices drivers for various operating system and is currently one of the leads in the Open Source driver group responsible for six Linux kernel drivers.

Participants:
attending therbert (Tom Herbert)

Microconfs:
  • Networking
Nautilus 5 Go to Blueprint
12:25 - 13:20 PDT
Lunch
13:20 - 14:05 PDT
[Slides](http://www.linuxplumbersconf.org/2012/wp-content/uploads/2012/08/laurent-pinchart-linux-display-and-video.pdf) The Linux kernel offers three APIs to display video and graphics. While DRM/KMS, FB and V4L2 started as solutions to distinct problems, they now largely overlap, resulting in confusion and code duplication. Several efforts have been or are being led to consolidate our display and video APIs and reduce code duplication. Despite them too many application developers are still lost when they need to select an API for display and video. This track will briefly present the ongoing work on DRM/KMS, FB and V4L2 that aim at reducing code duplication and bridging the gaps between these APIs. It will then outline the use cases that each API targets and how they can collaborate, to finally try and define rules that governs what API to choose when writing new drivers and applications. The track's target audience is kernel and userspace developers who want to better understand the Linux kernel graphics and video APIs and their interactions, and share their opinions on directions for future developments. Laurent Pinchart has been a Linux enthusiast since 1997 and Linux kernel developer since 2001. He has written media-related Linux drivers for consumer and embedded devices, and is one of the Video4Linux core developers. Laurent is the founder and owner of Ideas on board, a company specialized in embedded Linux design and development. He gave Linux media-related talks at the FOSDEM, LPC and ELC. He currently works with the Renesas Linux kernel teams where he develops embedded video-related kernel subsystems.

Participants:
attending apm (Antti P Miettinen)
attending rsalveti (Ricardo Salveti)
attending srwarren (Stephen Warren)

Microconfs:
  • Presentations
Nautilus 1 Go to Blueprint
Not Attending Security and Storage ( Virtualization )
Virtualization Topics: 1. Virtualization Security Discussion 2. Storage Virtualization for KVM === Virtualization Security Discussion === This proposal is for a discussion of the threats facing Linux based Virtualization technologies and what can be done to help mitigate these threats. The focus will be on hypervisor based virtualization, e.g. KVM, but container based virtualization can also be discussed if there is sufficient interest among the attendees. Possible topics of discussion include: * Confining malicious/exploited guests * Validating host identity and integrity from the guest * Enforcing network separation/virtualization Topic Lead: Paul Moore Paul has been involved in various Linux security efforts for the past eight years, with a strong focus on mandatory access control and network security. He has served as the Linux Kernel's labeled networking maintainer since 2007. Paul has given a number of presentations over the years at Linux conferences on Linux security, SELinux, SELinux/MLS, and labeled networking. === Storage Virtualization for KVM === In KVM based virtualization ecosystem, there are multiple choices for filesytem/storage and management tools. While this allows for different custom solutions, there is no single default storage solution that caters to the majority of use case scenarios. In this presentation, we will look at integrating different individual projects like QEMU, GlusterFS, oVirt/VDSM and libstoragemgmt to arrive at one filesystem/storage solution for KVM that works for most of the scenarios. Various aspects like making GlusterFS virtualization-ready and cross-vendor storage array integration will be discussed. We will finally discuss how some of the virtualization features like VM migration, taking snapshots etc can be done seamlessly in our storage solution using oVirt. Virtualization/Data Center administrators and users of KVM based virtualization will benefit from attending this presentation. Topic Lead: Bharata B Rao <email address hidden> Bharata B Rao is part of IBM Linux Technology Center, Bangalore He is currently working in the area of Virtualization. Earlier he has worked in the area of File Systems, Scheduler, Debuggers, Embedded Linux and Linux Clusters. Bharata graduated from The National Institute of Engineering, Mysore in 1999 and did his post graduation(MS) from BITS, Pilani in 2003. In his spare time, Sanskrit language, Mountains and Mridangam (an Indian percussion instrument) keep him engaged. Topic Lead: Deepak C Shetty <email address hidden> Deepak C Shetty is working with IBM's Linux Technology Center (LTC), Bangalore in the area of open virtualisation. Earlier he has worked in area of Virtualisation aware File Systems. Prior to being part of LTC, Deepak worked in the areas of Platform Management (IBM Systems Director product) and Hardware Validation of IBM Power systems, in IBM. Deepak holds a Bachelor of Engineering degree in Electronics from Pune University, India and Diploma in Advanced Computing from C-DAC, Pune, India. Other areas of interest include Software design and Stamp collection (Philately). Topic Lead: M Mohan Kumar <email address hidden> M. Mohan Kumar is an open source developer working at IBM Linux Technology Center, Bangalore. He has contributed to various components of Linux ecosystem including kexec (fast boot), kdump (kernel crash dump mechanism) for PowerPC, 9p file system and QEMU. Prior to IBM he has worked on various SCSI and Fibre Channel related Linux projects. Mohan obtained his Bachelor of Engineering in Computer Science and Engineering from Bharathiar University, TamilNadu, India. He has 11 years of experience in Linux area. Topic Lead: Balamurugan Aramugam <email address hidden> Balamurugan works as Principle Software Engineer in Red Hat. He is contributor to the upstream VDSM project, focusing on adding Gluster support. He has been involved in design/development of various Gluster products, FreeIPMI etc. Balamurugan works out of the Red Hat office in Bengaluru and his topics of interest include cloud technologies, Big Data, Kernel Development, Artificial Intelligence etc Topic Lead: Shireesh Anjal <email address hidden> Shireesh Anjal works as a Principal Software Engineer with Red Hat. He is a contributor to the upstream oVirt project, focusing on adding GlusterFS support. He has been involved with building scalable Banking and eGovernance systems over the past 12 years. Shireesh works out of the Red Hat office in Bengaluru and his topics of interest include cloud technologies, Big Data and mobile computing.

Participants:
attending amitshah (Amit Shah)
attending eblake (Eric Blake)
attending lpc-virt-lead (LPC Virtualization Lead)
attending paulmoore (Paul Moore)
attending stefano-stabellini (Stabe)

Microconfs:
  • Virtualization
Nautilus 2 Go to Blueprint

Microconfs:
  • Kernel Summit
Nautilus 3
Containers Topics: 1) Status of cgroups 2) CRIU - Checkpoint/Restore in Userspace 3) Kernel Memory accounting - memcg 4) ploop - container in a file 5) /proc virtualization 6) Building application sandboxes on top of LXC and KVM with libvirt 7) Syslog Virtualization 8) Time Virtualization cgroups are a crucial part of containers technologies, providing resource isolation and allowing multiple independent tasks to run without harming each other (too much) when it comes to shared resource usage. It is, however, a quite controvertial piece of the Linux Kernel, with a lot of work being done lately to revert that. We should discuss what kind of changes core cgroup users should expect, how to cope with them. === CRIU - Checkpoint/Restore in Userspace === Checkpoint/Restore functionality was attempted to be merged into the kernel many times, all without much success. CRIU is an attempt to solve the problem in userspace, augmenting the kernel functionality only when absolutely needed to aid that. === Kernel Memory accounting - memcg === The cgroup memory controller is already well established in the kernel. Recently, work is being done into adding kernel memory tracking to it. Patches exist for a part of it. We could use this session to explore possibly uncovered areas, and discuss the use cases. === ploop - container in a file === When dealing with container filesystems, some problems arise: How to limit the amount of data a container uses, since quota solutions that are container aware are not there yet. Also, when migrating the container to another destination, one usually remakes the filesystem by copying over the files (unless shared storage is assumed). This means that inode numbers are not preserved and also creates a bad I/O pattern of randomly copying over a zillion of tiny files, much slower than copying image of block-device (seq I/O). Another problem with all CTs sharing host fs is non-scalable journal on host fs: as soon as one CT filled the journal, other CTs should wait for its freeing. === /proc virtualization === When we run a fully featured container, we need a containerized view of the proc filesystem. Current upstream kernel can do that for the process tree and a few other things, but that is just not enough. For running top, for instance, one needs to know not only that, but also how much cpu time each container used in total, how much of that is system time, for how long that container was out of the CPU, etc. That information is available - or will be (some if it is patches pending) in different cgroups. What are the best ways to achieve this? What problems will we face? Is there any value in keep trying to push this functionality into the kernel, or would a userspace implementation suffice ? === Building application sandboxes on top of LXC and KVM with libvirt === This session will provide an overview of the recent virt-sandbox project, which aims to provide sandboxing of applications via the use of lightweight guests (both KVM and LXC). Discussion will cover techniques such as sVirt (use of SELinux labeling to prevent the sandboxed virtual machine/container from altering unauthorized resources in the host) and filesystem sharing & isolation (to allow the guest to share a specified portion of the host file system), integration with systemd for containerized application management, and tools to facilitate setup of sandboxed application service environments Topic Lead: Daniel Berrange Daniel has been the lead architect & developer of libvirt for more than 5 years, original developer of the libvirt-sandbox, virt-manager & entangle applications, and part-time hacker on QEMU, KVM, OpenStack, GTK-VNC, SPICE and more. === Syslog Virtualization === There is currently one buffer in the system to hold all messages generated by syslog. It would be ideal to have access to the syslog buffer in a per-container manner for isolation purposes. === Time Virtualization === Containers should have an independent and stable notion of time that is independent of the host. This is specially important when live migrating them around. It should also be perfectly possible for a process running gettimeofday() in a container to get a different value than the host system. We will discuss strategies to achieve that.

Participants:
attending kir-openvz (Kir Kolyshkin)

Microconfs:
  • Containers
Nautilus 4 Go to Blueprint
Despite more than 20 years of active research and development, non-blocking technologies remain inaccessible to many students, engineers and open-source projects. This is especially true in the context of an unmanaged language such as C despite its popularity in highly complex concurrent systems. Even in light of attractive performance properties, small to medium-sized corporations are extremely hesitant in adopting patent-free technology due to the technology lock-down associated with the various interfaces of existing concurrency libraries. To top it off, when introducing engineers to this area, many are overwhelmed by the literature and the sparsity of performance data. This topic will walk the audience through the story of the struggles Samy and his peers have faced in the last couple of years in developing sufficient working knowledge to (efficiently) leverage existing non-blocking data structures as well as design, implement and verify new algorithms for use by mission-critical systems. It will highlight the holes faced in existing open-source projects tackling the concurrency problem for the C programming language and the literature associated with much of existing technology. The culmination of frustrations lead to the development of Concurrency Kit, a library designed to aid in the design and implementation of high performance concurrent systems. It is designed to minimize dependencies on operating system-specific interfaces and most of the interface relies only on a strict subset of the standard library and more popular compiler extensions. Topic Lead: Samy Bahra <email address hidden> Samy is an engineer focused on developing a leading, real-time low latency online advertising platform. Before moving to New York, Samy played a crucial role on the engineering team behind the leading high-performance messaging platform. Prior to that, he was an active member of a high-performance computing laboratory and was primarily involved with Unified Parallel C and the performance modeling and analysis of shared-memory multi-processor systems. He has been involved with several open-source projects.

Participants:
attending mathieu-desnoyers (Mathieu Desnoyers)
attending paulmck (Paul McKenney)

Microconfs:
  • Scaling
Nautilus 5 Go to Blueprint
14:10 - 14:55 PDT
Containers Topics: 1) Status of cgroups 2) CRIU - Checkpoint/Restore in Userspace 3) Kernel Memory accounting - memcg 4) ploop - container in a file 5) /proc virtualization 6) Building application sandboxes on top of LXC and KVM with libvirt 7) Syslog Virtualization 8) Time Virtualization cgroups are a crucial part of containers technologies, providing resource isolation and allowing multiple independent tasks to run without harming each other (too much) when it comes to shared resource usage. It is, however, a quite controvertial piece of the Linux Kernel, with a lot of work being done lately to revert that. We should discuss what kind of changes core cgroup users should expect, how to cope with them. === CRIU - Checkpoint/Restore in Userspace === Checkpoint/Restore functionality was attempted to be merged into the kernel many times, all without much success. CRIU is an attempt to solve the problem in userspace, augmenting the kernel functionality only when absolutely needed to aid that. === Kernel Memory accounting - memcg === The cgroup memory controller is already well established in the kernel. Recently, work is being done into adding kernel memory tracking to it. Patches exist for a part of it. We could use this session to explore possibly uncovered areas, and discuss the use cases. === ploop - container in a file === When dealing with container filesystems, some problems arise: How to limit the amount of data a container uses, since quota solutions that are container aware are not there yet. Also, when migrating the container to another destination, one usually remakes the filesystem by copying over the files (unless shared storage is assumed). This means that inode numbers are not preserved and also creates a bad I/O pattern of randomly copying over a zillion of tiny files, much slower than copying image of block-device (seq I/O). Another problem with all CTs sharing host fs is non-scalable journal on host fs: as soon as one CT filled the journal, other CTs should wait for its freeing. === /proc virtualization === When we run a fully featured container, we need a containerized view of the proc filesystem. Current upstream kernel can do that for the process tree and a few other things, but that is just not enough. For running top, for instance, one needs to know not only that, but also how much cpu time each container used in total, how much of that is system time, for how long that container was out of the CPU, etc. That information is available - or will be (some if it is patches pending) in different cgroups. What are the best ways to achieve this? What problems will we face? Is there any value in keep trying to push this functionality into the kernel, or would a userspace implementation suffice ? === Building application sandboxes on top of LXC and KVM with libvirt === This session will provide an overview of the recent virt-sandbox project, which aims to provide sandboxing of applications via the use of lightweight guests (both KVM and LXC). Discussion will cover techniques such as sVirt (use of SELinux labeling to prevent the sandboxed virtual machine/container from altering unauthorized resources in the host) and filesystem sharing & isolation (to allow the guest to share a specified portion of the host file system), integration with systemd for containerized application management, and tools to facilitate setup of sandboxed application service environments Topic Lead: Daniel Berrange Daniel has been the lead architect & developer of libvirt for more than 5 years, original developer of the libvirt-sandbox, virt-manager & entangle applications, and part-time hacker on QEMU, KVM, OpenStack, GTK-VNC, SPICE and more. === Syslog Virtualization === There is currently one buffer in the system to hold all messages generated by syslog. It would be ideal to have access to the syslog buffer in a per-container manner for isolation purposes. === Time Virtualization === Containers should have an independent and stable notion of time that is independent of the host. This is specially important when live migrating them around. It should also be perfectly possible for a process running gettimeofday() in a container to get a different value than the host system. We will discuss strategies to achieve that.

Participants:
attending kir-openvz (Kir Kolyshkin)

Microconfs:
  • Containers
Nautilus 4 Go to Blueprint
[Slides](http://www.linuxplumbersconf.org/2012/wp-content/uploads/2012/08/sparse-improvements-LPC-2012.pdf) Virtual disk images have proven to be an interesting example of large sparse files. They often contain several gigabytes of data, interspersed with potentially large holes, and are often accessed over networks such as via NFS or iSCSI. In managing these files on the host, applications such as libvirt have run into scenarios where performance can be improved. For instance, it should be possible to quickly identify and alter sections of a file that are sparse, to perform a one-time copy of a disk image without polluting the host's file system cache, to expose any ability of underlying storage devices to do copy-on-write cloning, and to conditionally probe file characteristics without hanging if the file is no longer accessible due to a network outage. Sparse file handling has improved with recent lseek(SEEK_HOLE) additions, as well as new ioctls to punch holes into existing files, although this support is still not available to all file systems. Right now, the only way to avoid polluting the host's file system cache is to use O_DIRECT, but this makes life much more difficult for the application to conform to particular I/O patterns. The posix_fadvise() interface appears to provide the framework for asking the kernel to perform uncached operations without making the application worry about strict alignment, but for this to be useful, the kernel would need to provide additional guarantees (perhaps in sysfs) about what guarantees are possible through posix_fadvise. BTFRS and other file systems are starting to provide copy-on-write file cloning at a file system level, and there are also storage devices that still have varying controls to achieve the same effects at a device level; coming up with a unified interface to request this feature would be handy. Finally, the proposed xstat() kernel interface to conditionally control how much data is retrieved when querying file metadata would make it easier to work with large files that live across potentially unreliable network connections. Discussion will focus on interaction between kernel, file systems, and user space applications, to determine how to improve existing interfaces (such as posix_fadvise) or add new interfaces (such as xstat) that can be used to improve performance of large files. While my background for this proposal stems from handling of virtual disk images, there are probably several other file types that will benefit from improvements in this area. Eric Blake (Red Hat) is currently a primary contributor to the libvirt project, which presents a unified management interface into multiple virtualization technologies, such as KVM, LXC, and Xen. He is also active in the Austin Group for developing POSIX interfaces, as well as a contributor to the gnulib project for providing ports of POSIX and other interfaces to a large variety of platforms.

Participants:
attending eblake (Eric Blake)

Microconfs:
  • Presentations
Nautilus 1 Go to Blueprint
=== HD-Audio Cooking Recipe === This session will cover the debugging practices for typical problems seen with HD-audio, which is the standard component on all modern PCs, using the sysfs kernel interface and user-space helper programs. Also, we will discuss open problems, jack retasking, HDMI stream assignment, missing speaker/mic streams, and better interaction / organization with user-space applications like PulseAudio. === Bug Tracking and QA === Bug tracking in the sound subsystem is far away from the optimal situation. We'd like to discuss how to improve the situation, looking through the experiences from the current ALSA and distro bug trackers. Also, we're going to show the automated testing of HD-audio driver using hda-emu emulator for detecting the errors and regression coverage. Topic Lead: Takashi Iwai (<email address hidden>) Working as a member of hardware-enablement team in SUSE Labs at SUSE Linux Products GmbH in Nuremberg, Germany, while playing a role as a gatekeeper of the Linux sound subsystem tree over years. Topic Lead: David Henningsson (<email address hidden>) Working for Canonical with audio hardware enablement, fixing audio bugs and maintaining the audio stack, and also part of PulseAudio's current development team.

Participants:
attending broonie (Mark Brown)
attending diwic (David Henningsson)
attending srwarren (Stephen Warren)
attending tiwai (Takashi Iwai)

Microconfs:
  • Audio
Nautilus 2 Go to Blueprint

Microconfs:
  • Kernel Summit
Nautilus 3
=== Task placement for asymmetric cores === Traditional SMP scheduling is basically aiming for equal load distribution across all CPUs. To take full advantage of the big.LITTLE MP power/performance heterogeneity, task affinity is crucial. I have experimented with modifications to the Linux scheduler, which attempt to minimizing power consumption by selecting task affinity appropriately for each task. Topic Lead: Morten Rasmussen === Scheduling and the big.LITTLE Architecture === ARM's big.LITTLE architecture is an example of asymmetric multiprocessing where all CPUs are instruction-set compatible, but where different CPUs have very different performance and energy-efficiency characteristics. In the case of big.LITTLE, the big CPUs are Cortex-A15 CPUs with deep pipelines and numerous functional units, providing maximal performance. In contrast, the LITTLE CPUs are Cortex-A7 with short pipelines and few functional units, which optimizes for energy efficiency. Linaro is working on two methods of supporting big.LITTLE systems. One way to configure big.LITTLE systems is in an MP configuration, where both the big and LITTLE CPUs are present. Traditionally, most SMP operating systems have assumed that all CPUs are identical, but this is emphatically not the case for big.LITTLE. Therefore, changes for big.LITTLE are required. This talk will give an overview of the progress towards the goal of big.LITTLE support in the Linux plumbing. Topic Lead: Paul E. McKenney === cpuquiet: Dynamic CPU core management === [Slides](http://www.linuxplumbersconf.org/2012/wp-content/uploads/2012/08/cpuquiet.pdf) NVIDIA Tegra30 has CPU clusters with different abilities. There is a fast cluster with 4 cortex A9 cores and a low power cluster with a single cortex A9 core. Only 1 of the clusters can be active at a time. This means the number of available cores for the kernel changes at runtime. Currently we use CPU hotplug to make cores unavailable so we can initiate a switch to the low power cluster. This has a number of problems such as long latencies in switching between the clusters. Therefor a new mechanism where CPUs would not be available but still not completely removed from the system, would be useful. CPUs in this quiet state would not be running any userspace or kernelspace code, until they are explicitly made available again. The kernel datastructures associated with each CPU would be preserved however so a transitions can be a low latency operations. The policy can be encapsulated in a governor, like the cpufreq and cpuidle governors we already have. Topic Lead: Peter De Schrijver Peter is an NVIDIA Tegra Linux kernel engineer, Debian developer, previously working on power management in maemo for Nokia.

Participants:
attending apm (Antti P Miettinen)
attending paulmck (Paul McKenney)
attending srwarren (Stephen Warren)
attending vincent-guittot (Vincent Guittot)

Microconfs:
  • Scheduler
Nautilus 5 Go to Blueprint
15:00 - 15:45 PDT
Containers Topics: 1) Status of cgroups 2) CRIU - Checkpoint/Restore in Userspace 3) Kernel Memory accounting - memcg 4) ploop - container in a file 5) /proc virtualization 6) Building application sandboxes on top of LXC and KVM with libvirt 7) Syslog Virtualization 8) Time Virtualization cgroups are a crucial part of containers technologies, providing resource isolation and allowing multiple independent tasks to run without harming each other (too much) when it comes to shared resource usage. It is, however, a quite controvertial piece of the Linux Kernel, with a lot of work being done lately to revert that. We should discuss what kind of changes core cgroup users should expect, how to cope with them. === CRIU - Checkpoint/Restore in Userspace === Checkpoint/Restore functionality was attempted to be merged into the kernel many times, all without much success. CRIU is an attempt to solve the problem in userspace, augmenting the kernel functionality only when absolutely needed to aid that. === Kernel Memory accounting - memcg === The cgroup memory controller is already well established in the kernel. Recently, work is being done into adding kernel memory tracking to it. Patches exist for a part of it. We could use this session to explore possibly uncovered areas, and discuss the use cases. === ploop - container in a file === When dealing with container filesystems, some problems arise: How to limit the amount of data a container uses, since quota solutions that are container aware are not there yet. Also, when migrating the container to another destination, one usually remakes the filesystem by copying over the files (unless shared storage is assumed). This means that inode numbers are not preserved and also creates a bad I/O pattern of randomly copying over a zillion of tiny files, much slower than copying image of block-device (seq I/O). Another problem with all CTs sharing host fs is non-scalable journal on host fs: as soon as one CT filled the journal, other CTs should wait for its freeing. === /proc virtualization === When we run a fully featured container, we need a containerized view of the proc filesystem. Current upstream kernel can do that for the process tree and a few other things, but that is just not enough. For running top, for instance, one needs to know not only that, but also how much cpu time each container used in total, how much of that is system time, for how long that container was out of the CPU, etc. That information is available - or will be (some if it is patches pending) in different cgroups. What are the best ways to achieve this? What problems will we face? Is there any value in keep trying to push this functionality into the kernel, or would a userspace implementation suffice ? === Building application sandboxes on top of LXC and KVM with libvirt === This session will provide an overview of the recent virt-sandbox project, which aims to provide sandboxing of applications via the use of lightweight guests (both KVM and LXC). Discussion will cover techniques such as sVirt (use of SELinux labeling to prevent the sandboxed virtual machine/container from altering unauthorized resources in the host) and filesystem sharing & isolation (to allow the guest to share a specified portion of the host file system), integration with systemd for containerized application management, and tools to facilitate setup of sandboxed application service environments Topic Lead: Daniel Berrange Daniel has been the lead architect & developer of libvirt for more than 5 years, original developer of the libvirt-sandbox, virt-manager & entangle applications, and part-time hacker on QEMU, KVM, OpenStack, GTK-VNC, SPICE and more. === Syslog Virtualization === There is currently one buffer in the system to hold all messages generated by syslog. It would be ideal to have access to the syslog buffer in a per-container manner for isolation purposes. === Time Virtualization === Containers should have an independent and stable notion of time that is independent of the host. This is specially important when live migrating them around. It should also be perfectly possible for a process running gettimeofday() in a container to get a different value than the host system. We will discuss strategies to achieve that.

Participants:
attending kir-openvz (Kir Kolyshkin)

Microconfs:
  • Containers
Nautilus 4 Go to Blueprint
=== Task placement for asymmetric cores === Traditional SMP scheduling is basically aiming for equal load distribution across all CPUs. To take full advantage of the big.LITTLE MP power/performance heterogeneity, task affinity is crucial. I have experimented with modifications to the Linux scheduler, which attempt to minimizing power consumption by selecting task affinity appropriately for each task. Topic Lead: Morten Rasmussen === Scheduling and the big.LITTLE Architecture === ARM's big.LITTLE architecture is an example of asymmetric multiprocessing where all CPUs are instruction-set compatible, but where different CPUs have very different performance and energy-efficiency characteristics. In the case of big.LITTLE, the big CPUs are Cortex-A15 CPUs with deep pipelines and numerous functional units, providing maximal performance. In contrast, the LITTLE CPUs are Cortex-A7 with short pipelines and few functional units, which optimizes for energy efficiency. Linaro is working on two methods of supporting big.LITTLE systems. One way to configure big.LITTLE systems is in an MP configuration, where both the big and LITTLE CPUs are present. Traditionally, most SMP operating systems have assumed that all CPUs are identical, but this is emphatically not the case for big.LITTLE. Therefore, changes for big.LITTLE are required. This talk will give an overview of the progress towards the goal of big.LITTLE support in the Linux plumbing. Topic Lead: Paul E. McKenney === cpuquiet: Dynamic CPU core management === [Slides](http://www.linuxplumbersconf.org/2012/wp-content/uploads/2012/08/cpuquiet.pdf) NVIDIA Tegra30 has CPU clusters with different abilities. There is a fast cluster with 4 cortex A9 cores and a low power cluster with a single cortex A9 core. Only 1 of the clusters can be active at a time. This means the number of available cores for the kernel changes at runtime. Currently we use CPU hotplug to make cores unavailable so we can initiate a switch to the low power cluster. This has a number of problems such as long latencies in switching between the clusters. Therefor a new mechanism where CPUs would not be available but still not completely removed from the system, would be useful. CPUs in this quiet state would not be running any userspace or kernelspace code, until they are explicitly made available again. The kernel datastructures associated with each CPU would be preserved however so a transitions can be a low latency operations. The policy can be encapsulated in a governor, like the cpufreq and cpuidle governors we already have. Topic Lead: Peter De Schrijver Peter is an NVIDIA Tegra Linux kernel engineer, Debian developer, previously working on power management in maemo for Nokia.

Participants:
attending apm (Antti P Miettinen)
attending paulmck (Paul McKenney)
attending srwarren (Stephen Warren)
attending vincent-guittot (Vincent Guittot)

Microconfs:
  • Scheduler
Nautilus 5 Go to Blueprint
The usefulness of our existing plumbing is maximized by making sure it can be accessed programatically. Shelling out to their cmdline utilities is not good enough. Much plumbing has APIs, but many (e.g. iptables, open-iscsi, e2fsprogs, lvm, btrfs?) only have command-line utilities that limits their use as building blocks. We should establish that plumbing needs proper interfaces (.so, dbus, whatever) for other code to call it reliably, and that cmdline interfaces should really just be for humans. My hope is this session can discuss the issue, and possibly come to a greater consensus on the need for APIs in plumbing, and start making plans for how we can work towards more complete API coverage. Andy Grover is a kernel/plumbing guy who has worked on ACPI, networking, dmaengine, InfiniBand, and SCSI kernel target subsystems. His most recent work has also involved user-level code in Python and C. He lives in Portland, Oregon and works for Red Hat.

Participants:
attending e-bjarne-n (Bjarne Rosengren)
attending eblake (Eric Blake)
attending ezannoni-7 (LPC Submitter)

Microconfs:
  • Presentations
Nautilus 1 Go to Blueprint
Not Attending x86 Virtualization ( Virtualization )
Virtualization Topics: 2) COLO: COarse-grain LOck-stepping Virtual Machines for Non-stop Service - Eddie Dong 3) Reviewing Unused and Up-coming Hardware Virtualization Features - Jun Nakajima 4) Next Generation Interrupt Virtualization for KVM - Joerg Roedel === COLO: COarse-grain LOck-stepping Virtual Machines for Non-stop Service === Virtual machine (VM) replication (replicating the state of a primary VM running on a primary node to a secondary VM running on a secondary node) is a well known technique for providing application-agnostic, non-stop service. Unfortunately, existing VM replication approaches suffer from excessive replication overhead and, for client-server systems, there is really no need for the secondary VM to match its machine state with the primary VM at all times. We propose COLO (COarse-grain LOck-stepping virtual machine solution for non-stop service), a generic and highly efficient non-stop service solution, based on on-demand VM replication. COLO monitors the output responses of the primary and secondary VMs. COLO considers the secondary VM a valid replica of the primary VM, as long as network responses generated by the secondary VM match that of the primary. The primary VM state is propagated to the secondary VM, if and only if outputs from the secondary and primary servers no longer match. Topic Lead: Eddie Dong === Reviewing Unused and Up-coming Hardware Virtualization Features === We review unused and up-coming hardware virtualization (Intel VT) features to discuss how they can improve virtualization for open source. First, we review the existing hardware features that are not used by KVM or Xen today, showing examples for use cases. 1) For example, The descriptor-table exiting should be useful for the guest kernels or security agent to enhance security features. 2) The VMX-preemption timer allows the hypervisor to preempt guest VM execution after a specified amount of time, which is useful to implement fair scheduling. The hardware can save the timer value on each successive VM exit, after setting the initial VM quantum. 3) VMFUNC is an operation provided by the processor that can be invoked from VMX non-root operation without a VM exit. Today, EPTP switching is available, and we discuss how we can use the feature. Second, we talk about the new hardware features, especially for interrupt optimizations. Topic Lead: Jun Nakajima Jun Nakajima is a Principal Engineer leading open source virtualization projects, such as Xen and KVM at the Intel Open Source Technology Center. He presented a number of times at technical conferences, including Xen Summit, OLS, KVM Forum, and USENIX. === Next Generation Interrupt Virtualization for KVM === Virtualizing the x86 interrupt system is one of the most performance critical tasks a hypervisor has to implement. For some workloads the overhead of a soft-virtualized APIC can mean a significant performance degradation when running in a virtual machine. This talk introduces a hardware extension to reduce this overhead. It will be explained how this extension works and how we plan to integrate it into KVM. Topic Lead: Joerg Roedel

Participants:
attending amitshah (Amit Shah)
attending lpc-virt-lead (LPC Virtualization Lead)

Microconfs:
  • Virtualization
Nautilus 2 Go to Blueprint
Not Attending Kernel Summit Feedback ( Kernel Summit )

Microconfs:
  • Kernel Summit
Nautilus 3
16:00 - 17:30 PDT [PLENARY]
The Importance of Linux at Intel: Imad Sousou, Director, Intel Open Source Technology Center at 16:00 Join Imad Sousou as he discusses the significance of Linux development at Intel across a range of computing devices and platforms. He will share how Intel successfully and effectively contributes code upstream and how collaboration with the Linux and open source communities is a key component to creating and maintaining healthy open ecosystems. Open Cloud, Collapsing the Layers: Kyle MacDonald, VP of Cloud, Canonical at 16:20 With Ubuntu, the complexities of cloud computing become simple. This discussion will demystify Open Cloud and demonstrate how the layers of complexity can be collapsed by leveraging Ubuntu. You will be amazed how complex deployment instructions can be stored as charms and reused for consistent service orchestration using Juju. This is what we call DevOps Distilled. Whether you are looking to build on public clouds like AWS or Rackspace or create your own private cloud, this discussion will give you a clear road map on how to get there with Ubuntu. Keynote Panel: State of the Linux Kernel at 16:40 With Linus Torvalds, Greg Kroah-Hartman, Ted Ts'o, moderated by James Bottomley

Participants:
attending srwarren (Stephen Warren)
Grand Ballroom
18:00 - 21:30 PDT [PLENARY]
Sponsored by Qualcomm Innovation Center, Inc. and Code Aurora Forum
Offsite
< Wednesday >