X-Git-Url: https://git.decadent.org.uk/gitweb/?p=kernel-news-talk.git;a=blobdiff_plain;f=index.html;h=31c5d34d1e27a5330b890a9513c964c6e4932350;hp=a97baec9f54b327a200016606cda8a6bab6ed547;hb=refs%2Ftags%2Fdebconf2014;hpb=626d02f02e5ce148221d53216865cbcf07a36c21

diff --git a/index.html b/index.html
index a97baec..31c5d34 100644
--- a/index.html
+++ b/index.html
@@ -59,6 +59,7 @@
   <ul>
     <li>
       Professional software engineer by day, Debian developer by night
+      (or sometimes the other way round)
     </li>
     <li>
       Regular Linux contributor in both roles since 2008
@@ -85,7 +86,7 @@
       every week or two)
       <ul>
 	<li>
-	  ...though some features aren't ready to use when they firat
+	  ...though some features aren't ready to use when they first
 	  appear in a release
 	</li>
       </ul>
@@ -103,174 +104,306 @@
 </div>
 
 <div class="slide">
-  <h1>Team device driver [3.3]</h1>
+  <h1>Recap of last year's features (1)</h1>
   <ul class="incremental">
     <li>
-      Alternative to the bonding driver - simpler, modular, high-level
-      control deferred to userland
+      Team device driver: userland package (libteam) was uploaded in
+      October
     </li>
     <li>
-      Basic configuration can be done with <tt>ip</tt>, but it really
-      needs new tools - <tt>teamd</tt>, <tt>teamnl</tt>, etc.
+      Transcendent memory: frontswap, zswap and Xen tmem will be
+      enabled in next kernel upload
     </li>
     <li>
-      Make it work: see
-      <a href="http://bugs.debian.org/695850">http://bugs.debian.org/695850</a>
+      New KMS drivers: should all work with current Xorg drivers
+    </li>
+    <li>
+      Module signing: still not enabled, but probably will be if we
+      do Secure Boot
     </li>
   </ul>
 </div>
 
 <div class="slide">
-  <h1>Transcendent memory [3.0-3.5]</h1>
+  <h1>Recap of last year's features (2)</h1>
   <ul class="incremental">
     <li>
-      Abstract storage for memory pages, expected to be slower than
-      regular memory but faster than disk
+      More support for discard: still not enabled at install time
+      (<a href="https://bugs.debian.org/690977">#690977</a>)
+    </li>
+    <li>
+      More support for containers: XFS was fixed, and user namespaces
+      have been enabled
+    </li>
+    <li>
+      bcache: userland package (bcache-tools) still not quite ready
+      (<a href="https://bugs.debian.org/708132">#708132</a>)
+    </li>
+    <li>
+      ARMv7 multiplatform: d-i works on <em>some</em> platforms but
+      I'm still not sure which.  Some progress on GPU drivers, but not
+      in Debian yet.
     </li>
+  </ul>
+</div>
+
+<div class="slide">
+  <h1>Unnamed temporary files [3.11]</h1>
+  <ul>
     <li>
-      Can provide a second layer of page cache (cleancache and frontswap)
+      Open directory with option <tt>O_TMPFILE</tt> to create an
+      unnamed temporary file on that filesystem
     </li>
     <li>
-      Pages stored by hypervisor (Xen), compressed local memory
-      (zcache) or cluster of machines (RAMster)
+      As with <tt>tmpfile()</tt>, the file disappears on
+      last <tt>close()</tt>
     </li>
     <li>
-      Not yet enabled in Debian kernels, and needs some thought about
-      configuration
+      File can be linked into the filesystem using
+      <tt>linkat(..., AT_EMPTY_PATH)</tt>, allowing for 'atomic'
+      creation of file with complete contents and metadata
     </li>
     <li>
-      Make it work: see
-      <a href="https://lwn.net/Articles/454795/">https://lwn.net/Articles/454795/</a>
-      and send proposal to debian-kernel
+      Not supported on all filesystem types, so you will usually need
+      a fallback
     </li>
   </ul>
 </div>
 
 <div class="slide">
-  <h1>New KMS drivers [3.3-3.10]</h1>
+  <h1>Network busy-polling [3.11] (1)</h1>
+  <p>A conventional network request/response process looks like:</p>
+  <small><!-- ew -->
+    <ol class="incremental">
+      <li>
+	Task calls <tt>send()</tt>; network stack constructs a
+	packet; driver adds it to hardware Tx queue
+      </li>
+      <li>
+	Task calls <tt>poll()</tt> or <tt>recv()</tt>, which blocks;
+	kernel puts it to sleep and possibly idles the CPU
+      </li>
+      <li>
+	Network adapter receives response and generates IRQ, waking
+	up CPU
+      </li>
+      <li>
+	Driver's IRQ handler schedules polling of the hardware Rx
+	queue (NAPI)
+      </li>
+      <li>
+	Kernel runs the driver's NAPI poll function, which passes
+	the response packet into the network stack
+      </li>
+      <li>
+	Network stack decodes packet headers and adds packet to
+	the task's socket
+      </li>
+      <li>
+	Network stack wakes up sleeping task; scheduler switches
+	to it and the socket call returns
+      </li>
+    </ol>
+  </small>
+</div>
+
+<div class="slide">
+  <h1>Network busy-polling [3.11] (2)</h1>
   <ul class="incremental">
     <li>
-      DRM/KMS drivers added for old, new and virtual hardware -
-      AST, DisplayLink, Hyper-V, Matrox G200, QEMU Cirrus
+      If driver supports busy-polling, it tags each packet with
+      the receiving NAPI context, and kernel tags sockets
+    </li>
+    <li>
+      When busy-polling is enabled, <tt>poll()</tt>
+      and <tt>recv()</tt> call the driver's busy poll function to
+      check for packets synchronously (up to some time limit)
+    </li>
+    <li>
+      If the response usually arrives quickly, this reduces overall
+      request/response latency as there are no context switches and
+      power transitions
+    </li>
+    <li>
+      Time limit set by sysctl (<tt>net.busy_poll</tt>,
+      <tt>net.busy_read</tt>) or socket option (<tt>SOL_SOCKET,
+      SO_BUSY_POLL</tt>); requires tuning
+    </li>
+  </ul>
+</div>
+
+<div class="slide">
+  <h1>Lustre filesystem [3.12]</h1>
+  <ul>
+    <li>
+      A distributed filesystem, popular for cluster computing
+      applications
     </li>
     <li>
-      Should be more robust than purely user-mode drivers, and
-      compatible with Secure Boot
+      Developed out-of-tree since 1999, but now added to Linux staging
+      directory
     </li>
     <li>
-      Current X drivers don't work with these, so the kernel drivers
-      are disabled for now
+      Was included in squeeze but dropped from wheezy as it didn't
+      support Linux 3.2
     </li>
     <li>
-      Make it work: join the X Strike Force and package the new X
-      drivers
+      Userland is now missing from Debian
     </li>
   </ul>
 </div>
 
 <div class="slide">
-  <h1>Module signing [3.7]</h1>
+  <h1>Btrfs offline dedupe [3.12]</h1>
   <ul class="incremental">
     <li>
-      Kernel modules can be signed at build time, and the kernel
-      configured to refuse loading unsigned modules
+      Btrfs generally copies and frees blocks, rather than updating
+      in-place
+    </li>
+    <li>
+      This allows snapshots and file copies to copy-by-reference,
+      deferring the real copying until changes are made
     </li>
     <li>
-      Necessary but not sufficient to implement Secure Boot -
-      we would also need signed kernel images and some other
-      restrictions when booted in this mode
+      Filesystems may still end up with multiple copies of the same
+      file content
     </li>
     <li>
-      Make Secure Boot work: come to the meeting on Tuesday
+      Btrfs doesn't actively merge these duplicates, but userland can
+      tell it to do so
+    </li>
+    <li>
+      Many file dedupe tools are packaged for Debian, but not one that
+      works with this Btrfs feature, e.g. bedup
     </li>
   </ul>
 </div>
 
 <div class="slide">
-  <h1>More support for discard</h1>
+  <h1>nftables [3.13]</h1>
   <ul class="incremental">
     <li>
-      Flash devices (and thin-provisioned SANs) can be more efficient
-      if the filesystem 'discards' unused disk space
+      Linux has several firewall APIs - iptables, ip6tables, arptables
+      and ebtables
+    </li>
+    <li>
+      All limited to single protocol, and need a kernel module for
+      each match type and each action
+    </li>
+    <li>
+      Kernel's internal netfilter API is more flexible
     </li>
     <li>
-      Requires support in hardware, driver, filesystem and any layered
-      device drivers - e.g. LVM, RAID (added in 3.7)
+      nftables exposes more of this flexibility, allowing userland
+      to provide firewall code for a specialised VM (similar to BPF)
     </li>
     <li>
-      Must be explicitly enabled, but d-i doesn't do this by default
+      nftables userland tool uses this API and is already packaged
     </li>
     <li>
-      Make it work: fix <a href="http://bugs.debian.org/690977">http://bugs.debian.org/690977</a>
+      Eventually, old APIs will be removed and old userland
+      tools must be ported to use nftables
     </li>
   </ul>
 </div>
 
 <div class="slide">
-  <h1>More support for containers</h1>
+  <h1>User-space lockdep [3.14]</h1>
+  <ul>
+    <li>
+      Kernel threads and interrupts all run in same address space,
+      using several different synchronisation mechanisms
+    </li>
+    <li>
+      Easy to introduce bugs that can result in deadlock, but hard to
+      reproduce them
+    </li>
+    <li>
+      Kernel's 'lockdep' system dynamically tracks locking operations
+      and detects <em>potential</em> deadlocks
+    </li>
+    <li>
+      Now available as a userland library!  Except we need to package
+      it (build from linux-tools source package)
+    </li>
+  </ul>
+</div>
+
+<div class="slide">
+  <h1>arm64 and ppc64el ports</h1>
   <ul class="incremental">
     <li>
-      Containers are lightweight VMs - run on the same kernel as host,
-      but with limited privileges and resources
+      'arm64' architecture was added in Linux 3.7, but was not yet
+      usable, and no real hardware was available at the time
     </li>
     <li>
-      Previously done by OpenVZ and Linux-VServer; gradually being
-      reimplemented upstream
+      Upstream Linux arm64 kernel, and Debian packages, should now run
+      on emulators and real hardware
     </li>
     <li>
-      User namespaces (added in 3.7) support the existence of a
-      <tt>root</tt> user inside the container that is unprivileged
-      outside the container
+      'powerpc' architecture has been available for many years,
+      but didn't support kernel running little-endian
     </li>
     <li>
-      Currently somewhat experimental, and requires filesystem
-      changes which haven't been done for XFS
+      Linux 3.13 added little-endian kernel support, along with new
+      userland ELF ABI variant - we call it ppc64el
     </li>
     <li>
-      Make user namespaces work: send patches to upstream XFS
-      developers (this one's hard)
+      Both ports now being bootstrapped in unstable and are candidates
+      for jessie release
     </li>
   </ul>
 </div>
 
 <div class="slide">
-  <h1>bcache [3.10]</h1>
+  <h1>File-private locking [3.15]</h1>
   <ul class="incremental">
     <li>
-      Turns a fast block device into a cache for a larger, slower
-      device (see also: dm-cache, EnhanceIO)
+      POSIX says that closing a file descriptor removes
+      the <em>process</em>'s locks on that file
+    </li>
+    <li>
+      What if process has multiple file descriptors for the same
+      file?  It loses all locks obtained through any descriptor!
+    </li>
+    <li>
+      Multithreaded processes may require serialisation around
+      file open/close to ensure they open each file exactly once
     </li>
     <li>
-      Needs its own set of userland tools
+      Hard and symbolic links can hide that two files are really the
+      same
     </li>
     <li>
-      Make it work:
-      see <a href="http://bugs.debian.org/708132">http://bugs.debian.org/708132</a>
-      (maybe just needs a sponsor)
+      Linux now provides file-private locks, associated with a
+      specific open file and removed when last descriptor for the
+      open file is closed
     </li>
   </ul>
 </div>
 
 <div class="slide">
-  <h1>ARMv7 multiplatform</h1>
+  <h1>Multiqueue block devices [3.16]</h1>
   <ul class="incremental">
     <li>
-      Until recently, each ARM kernel image could support only a small
-      set of different chips
+      Each block device has a command queue (possibly shared with
+      other devices)
     </li>
     <li>
-      Debian 'armmp' kernel now supports ARMv7 SoCs from Calxeda,
-      Freescale and Marvell, and others should be supported soon
+      Queue may be partly implemented by hardware (NCQ) or only
+      in software
     </li>
     <li>
-      Debian could run on a much larger range of ARM hardware - but we
-      need installer and boot loader support to make this easy
+      A single queue means initiation is serialised and completion
+      involves IPI - can be bottleneck for fast devices
     </li>
     <li>
-      Make it work: join the ARM porters and d-i team
+      High-end SSDs support multiple queues, but kernel needed changes
+      to use them
     </li>
     <li>
-      Make the GPUs work: join a reverse-engineering project
+      <tt>mtip32xx</tt> driver now supports multiqueue, but SCSI
+      drivers don't yet - may be backport-able?
     </li>
   </ul>
 </div>