Linux Kernel Report (John Corbet)

Since 3.1: 65600 changesets, +1.32M lines

Most people don’t use mainline kernels, not even stable tree, but distributor kernel. Stable updates are now a bit more formalized: every kernel is kept in stable for 1 cycle (i.e. 3.5 until 3.7 is released).  Once a year a kernel is chosen for long-term (= 2 years), and occasionally one for even longer term.

Who contributes?

  • Over the long term, the number of contributors without affiliation is dropping slowly. Why? Easy problems have all been solved, the kernel is getting hard to come into, so difficult for volunteers. Also, if you are a volunteer contributor, you run a high chance of getting hired.
  • In recent years we see mobile and embedded corporate contributors picking up (TI, Samsung, Linaro). That is because mobile is becoming important, but also because those companies have become dedicated to working with the community.

What’s coming?

  • 3.7 expected early December
  • 64-bit ARM
  • Xen on ARM
  • IPv6 NAT
  • TCP fast open (server side; client side was already there)

CoDel queue manager (bufferbloat patch) merged in 3.5.

Linux is where the innovation happens in networks (cfr. TCP fast open, CoDel queue manager, NFC).

ARM mess: industry was starting to contribute back (like we asked), but they added a lot of code which was not so nice but was still accepted because we wanted this support in the mainline.  It’s getting cleaned up.

ARM big.LITTLE: combination of fast and slow cores; need AMP scheduler.

Security is nowadays taken seriously in Linux.  E.g. link restrictions that closes some generic attacks, or limiting access from kernel to userspace, or signed loading of kernel modules.

ext4 is still the workhorse filesystem, it’s still getting new features and won’t be replaced by btrfs in the near future. btrfs continues to stabilize.

CPU scheduling is still evolving: NUMA scheduler, power-aware scheduler.

Concerns about the kernel:

  • Testing is problematic, because problems tend to be hardware and workload dependent – so can’t be tested automatically. There are some tools to help with testing, e.g. linsched which simulates the scheduler on a bunch of workloads.  However, regressions aren’t tracked.  Regressions are important because they break things that work now.  Regression tracking tells you if you’re going in the right direction.  We don’t know that anymore.
  • Complexity: some parts nobody understands. This is driven by hardware complexity and software needs (e.g. lockless algorithms to ensure scalability) – e.g. RCU.
  • Innovation: interesting stuff is now done on Linux first (this used to be different), including which problems are the right problems that need to be solved.  This means the kernel ABI is no longer easy (just follow Posix and/or Solaris) – we have to invent new things and then we’re stuck with whatever we decide to go for.



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s