2011 09/17/2009 08/19/2009 99 Extensions to KVM and kernel bridge support of adapter based virtual switch, SNMP MIBs for bridges, network filtering in sr-iov switch and linux bridge using libvirt extensions, external network switching (VEPA) 08/19/2009 2011 09/23/2009 09/15/2009 110 "Multiseat":http://en.wikipedia.org/wiki/Multiseat_configuration holds tons of promise, but it has been very hard for end-users to configure for each different hardware setup. To take off, it must get easier. Inspired by the "Ndiyo project":http://www.ndiyo.org/news/open-source-hubster involving Dr. Quentin Stafford-Fraser and others, good progress has been made. This BoF session will start with a demonstration of plug and play multiseat running today on Ubuntu 9.04, showing several sets of USB displays, keyboards, and mice, each being plugged into the PC to pop up an additional terminal. The solution uses a DisplayLink USB kernel framebuffer device and open source driver, per "these instructions":http://libdlo.freedesktop.org/wiki/MultiSeatTerminal The BoF session will then open discussion up to the room on remaining problems -- including better integration with coming ConsoleKit & other changes, how best to tackle those problems, and how we can get this support widely integrated into Linux distros. 09/15/2009 2011 09/30/2009 08/20/2009 100 In today's computer world, we find that most processors have several embedded cores and hyper-threading. Most programmers do not really use these powerful features and let the operating system do the work. At most, a programmer will bound an application to a certain processor or assign an interrupt to a different processor. At the end, we get system busy in maintaining tasks across processors, balancing interrupts, flushing TLBs and DTLBs[1] using atomic operations even when not needed and worst of all, spin locks across processors in vein; and the more processors the merrier. I argue that in some cases, part of this behavior is due to fact the multiple core operating system is not service oriented but a system oriented. There is no easy way to assign a processor to do a distinct service, undisturbed, accurate, and fast as long as the processor is an active part of an operating system and still be a part of most of the operating system address space. OFFSCHED Purpose The purpose of the OFFSCHED is to create a platform for services. For example, assume a firewall is being attacked; the Linux operating system will generate endless number of interrupts and/or softirqs to analyze the traffic and throw out bad packets. This is on the expense of "good" packets. Have you ever tried to "ssh" to an attacked machine? What if we can simply do the packet analysis outside the operating system, without interrupts and still fast enough? Why not assign a core to do only "firewalling"? Or just routing? Design a new type of Real Time system? Maybe assign it as an ultra accurate timer? Create a delaying service that does not just spin? Offload a TCP stack? perhaps a new type of a locking scheme? New type bottom-halves? Debug a running kernel through an offloaded processor? Maybe assign a GPU to do other things than just graphics? Amdahl Law teaches us that linear speed-up is not very feasible [2] [3], so why not spare a processor to do certain tasks better? Technologically speaking, I am referring to the Linux kernel ability to virtually hot plug a (SMT) processor but instead of letting it wonder in endless "halts", assign it a service. OFFSCHED project can be found at : http://sos-linux.svn.sourceforge.net/viewvc/sos-linux/offsched/ I have implemented: 1. OFFSCHED-RT. A different kind of a real time system. 2. OFFSCHED-TIMER. a 1us timer. 3. OFFSCHED-RTOP. remote top. OFFSCHED throws top-like information to a nother machine, while the OFFSCHED machine is not accessible 4. OFFSCHED NAPI. offloaded NAPI 5. OFFCSHED SECURED. a firewall that protects the operating system. 08/20/2009 2011 09/15/2009 09/15/2009 111 Several developers working on the implementation of Checkpoint/Restart plan to be at the Plumbers Conference. This offers a good opportunity to discuss design, implementation, plans and priorities. A few other developers are interested in joining the discussion remotely, if teleconferencing facility is available. 09/15/2009 2011 09/22/2009 08/10/2009 95 Real Time Linux OFFLINE SCHEDULER In today's computer world, we find that most processors have several embedded cores and hyper-threading. Most programmers do not really use these powerful features and let the operating system do the work. At most, a programmer will bound an application to a certain processor or assign an interrupt to a different processor. At the end, we get system busy in maintaining tasks across processors, balancing interrupts, flushing TLBs and DTLBs[1] using atomic operations even when not needed and worst of all, spin locks across processors in vein; and the more processors the merrier. I argue that in some cases, part of this behavior is due to fact the multiple core operating system is not service oriented but a system oriented. There is no easy way to assign a processor to do a distinct service, undisturbed, accurate, and fast as long as the processor is an active part of an operating system and still be a part of most of the operating system address space. OFFSCHED Purpose The purpose of the OFFSCHED is to create a platform for services. For example, assume a firewall is being attacked; the Linux operating system will generate endless number of interrupts and/or softirqs to analyze the traffic and throw out bad packets. This is on the expense of "good" packets. Have you ever tried to "ssh" to an attacked machine? What if we can simply do the packet analysis outside the operating system, without interrupts and still fast enough? Why not assign a core to do only "firewalling"? Or just routing? Design a new type of Real Time system? Maybe assign it as an ultra accurate timer? Create a delaying service that does not just spin? Offload a TCP stack? perhaps a new type of a locking scheme? New type bottom-halves? Debug a running kernel through an offloaded processor? Maybe assign a GPU to do other things than just graphics? Amdahl Law teaches us that linear speed-up is not very feasible [2] [3], so why not spare a processor to do certain tasks better? Technologically speaking, I am referring to the Linux kernel ability to virtually hot plug a (SMT) processor but instead of letting it wonder in endless "halts", assign it a service. OFFSCHED project can be found at : http://sos-linux.svn.sourceforge.net/viewvc/sos-linux/offsched/ I have implemented: 1. OFFSCHED-RT. A different kind of a real time system. 2. OFFSCHED-TIMER. a 1us timer. 3. OFFSCHED-RTOP. remote top. OFFSCHED throws top-like information to a nother machine, while the OFFSCHED machine is not accessible 4. OFFSCHED NAPI. offloaded NAPI 5. OFFCSHED SECURED. a firewall that protects the operating system. 08/10/2009 2011 09/04/2009 08/29/2009 101 There are many decisions to make in packaging and maintaining Linux in distributions: - which version to release with - configuration options - how many different configurations - drivers to backport - bug fixes to backport (after the end of a stable series) How do we make this choices? What can we learn from other distributions? Can we cooperate to improve support over the lifetime of long-term releases? 08/29/2009 2011 09/23/2009 09/23/2009 112 Audio BoF 09/23/2009 2011 09/04/2009 08/10/2009 96 I want to give insights into the challenges of a "shared nothing" clustering storage replication solution has deal with. Besides the challenges some of the methods and algorithms used in DRBD-8 might get presented: data generation UUDIs, resync-bitmap, the activity log, detection of conflicting writes and barrier semantics mapping. The features that became available with the release of DRBD-8.3 will of course be presented as well: device stacking, checksum based resync. Which can be used to set up disaster recovery nodes in addition to a conventional cluster. DRBD can also be used to implement the "follow the sun" model. 08/10/2009 2011 09/04/2009 08/31/2009 102 There has been much work completed since the LPC 2008 decision to move LIO kernel code into to a generic target engine infrastructure using upstream configfs infrastructure as it's base. The Two major SPC-4 SCSI target mode fabric features that have been completed: Persistent Reservation APTPL and implict/explict ALUA are now the first all optional SPC4 defined feature implementation of PR and ALUA in the Linux OSS target theatre using an upstream user-driven virtual filesystem directory hierarchy structure that can be configured in realtime in combination with interpreted userspace code. 08/31/2009 2011 09/23/2009 09/23/2009 113 Paravirt I/O Drivers for Linux BoF 09/23/2009 2011 09/04/2009 08/10/2009 97 ScaleMP vSMP Foundation is a form of aggregation virtualization. vSMP Foundation is a distributed virtual machine monitor (VMM) aggregating multiple similar x86-64 systems to make a single large shared memory system. The multiple systems are interconnected to each other with a commodity fast interconnect (currently Infiniband). The vSMP Foundation VMM takes care of aggregating all the constituent hardware of the aggregated system. This implies that the VMM also takes care of the memory/cache coherency among the constituent systems. Currently Linux is the only guest operating system that is supported by the vSMP Foundation. The vSMP Foundation VMM implements multiple inter-node coherency mechanisms. The resulting shared memory architecture is both “NUMA” and “COMA” in nature. The coherency mechanism chosen is transparent as far as the guest kernel is concerned (Applications can explicity choose a coherency mechanism though). Due to the software approach to coherency, and speeds of the existing commodity interconnects the NUMA factor of the aggregated system is fairly large. The COMA coherency domain results in a large internode cacheline size — 4kB usually. Due to the above two reasons, cache misses and cacheline ping-pongs are a major issue. This BoF will focus on solutions employed in the kernel and applications to overcome performance penalties due to the NUMA factors and large cacheline. The effects due to the large cacheline show up in different ways — from the classical false sharing cases where traditional solutions based on padding could be employed to true sharing/lock contention cases where workarounds based on certain features in the Linux kernel and userspace libraries like hugetlb, libhugetlbfs, arena based allocations, third party malloc replacements, make more sense. This BoF will surmise all these workarounds and techniques used to date, some of the techniques we plan to use, and solicit suggestions on some unsolved issues. 08/10/2009 2011 09/23/2009 09/04/2009 103 When a process does some number crunching for a while, without involving the kernel, the kernel still interrupts it HZ times per second to figure out if it has any work to do. With a system dedicated to doing such number crunching, the answer will almost always come up "no"; however, the kernel takes a while figuring out all the "no"s from various subsystems, every timer tick. On my system, the timer tick takes about 80us, every 1/HZ seconds; that represents a significant overhead. 80us out of every 1ms, for instance, means 8% overhead. Furthermore, the time taken varies, and the timer interrupts lead to jitter in the performance of the number crunching. The kernel has long had a "tickless" or "nohz" mechanism to shut down the timer tick when not needed, but this mechanism only works when idle, not when running. If every function currently polling from the timer tick could instead make use of an appropriate event, or just wait to get updated until the next time the kernel has work to do, the kernel could become entirely event-driven. A prototype[1] of a truly tickless Linux kernel demonstrated the improvement in performance and consistency demonstrated by removing the timer tick[2][3]. Making this a reality, though, requires reworking all the bits hanging off the timer tick. [1] http://lkml.org/lkml/2009/9/1/229 [2] http://lkml.org/lkml/2009/9/3/7 [3] http://ozlabs.org/~anton/linux/osjitter/ An event-driven kernel would improve throughput by decreasing interruptions, improve latency by removing large non-preemptible regions, improve consistency by eliminating the primary source of jitter, and improve power savings by getting done and back to sleep sooner. So, if the kernel has you ticked, come to this BoF, and we'll get you ticked off in a jiffy. 09/04/2009 2011 09/24/2009 09/24/2009 114 Data Center Bridging 09/24/2009 2011 09/13/2009 08/10/2009 98 In order to support the much more complex media hardware like the omap or davinci SoCs a new framework is needed. The initial ideas were formed during last year's Plumbers and I will give an overview of what has happened since then. During this year's Plumbers we discussed the next phase: how to give embedded developers access to the hardware allowing them to control it optimally. I will present our plans to implement this. There will also be an overview of other proposals such as HDTV support. 08/10/2009