If you don't closely follow the development of Linux kernel, now is the best time to catch up.

UPDATE: There's a brief report by LWN.

There are many papers on virtualization, such as Xen and kvm.
Also many papers talk about debugging and tracing, in particular kernel-based tracing.

Below I've picked out some papers of interest to me:
0. Linux Kernel Debugging on Google-sized clusters describes a kernel tracing system designed to debug intermittent bugs that are not easily reproducible. The system is lightweight enough to run on production systems all the time, and allows for an abritrary event to trigger trace collection when the bug occurs. Two tracing tools, Google's Ktrace and the open source LTTng tool is used. The system collects trace data whenever a trace point is encountered in the kernel, and copies the data to user-space buffer using the high speed Relay system.
1. Ltrace internals explains the code function by function.
2. ACPI in Linux -- Myths vs. Reality presents a historic overview of APM and ACPI, along with issues with SMP systems. Suprisingly, when ACPI on Linux fails, instead of blaming buggy BIOS, the majority of bugs are due to Linux implementation. BIOS vendors can test their compatability with Linux using the Linux-ready Firmware Developer Kit.
3. Frysk 1, Kernel 0? very briefly presents a promising debugger and monitor. I was able to install it on Debian and monitor events in other processes. I didn't figure out how to run the debugger.
4. Keeping Kernel Performance from Regressions introduces the Linux Kernel Performance project. The project automatically checks out new -rc version or -git version and runs them on a set of machines with Intel processors to find any significant performance regressions. The benchmarks used include SPEC CPU 2000 and a bunch of other test suites. The section Dealing with Test Variation is an interesting read.
5. The 7 dwarves: debugging information beyond gdb is about inspection tools that can extract information about data structures, diff two object files, pretty print dwarf info, etc. It also mentions a useful tool, elfutils. On Debian, you need the following commands to get, build, and run the code:

apt-get install git-core cmake libebl-dev libdw-dev
git-clone git://git.kernel.org/pub/scm/linux/kernel/git/acme/pahole.git
.
UPDATE: Go to http://www.youmustbejoking.demon.co.uk/progs.sid.html#pahole for .deb.
6. Ptrace, Utrace, Uprobes: Lightweight, Dynamic Tracing of User Apps did a good job summarizing strace, ltrace, ptrace, kprobes, utrace, uprobes, systemtap, dprobes, and dtrace. Utrace is going to replace ptrace, because ptrace is non-standard and incurs huge overhead. Utrace's applications include a ptrace interface and uprobes. Just as kprobes creates and manages probepoints in kernel code, uprobes does so in user applications.
7. Extreme High Performance Computing or Why Microkernels suck takes another look at the Holy War between monolithic kernels and microkernels, after 15 years. According to the paper, the Linux people have scaled Linux to run on 4k processors with 8TB memory, with the potential to support 16k processors soon. Linux's view of memory is a single address space on a Non-Uniform Memory Architecture (NUMA), in which some memory is nearer to a processor than other memory. The OS needs to place the memory properly to reduce memory latencies. To assit the OS, a memory control API is supplied so that applications can set up memory allocation policies. The paper argues that microkernels have a few limitations in a large NUMA: a) the decision of choosing the right address of the message queue is high-overhead if handled by a dedicated subsystem; b) although a microkernel can isolate a failure into one component, it's not always easy to restart the component because relevant state information may be lost. Checkpointing is hard to do because state information scatters over modules. The paper then goes on to show the techniques developed to scale Linux.
8. Cleaning up the Linux desktop audio mess explains why the PulseAudio sound server is needed by presenting the historic background of alsa, oss, jack, arts, and esd, and portaudio. Pulseaudio sits atop of OSS and ALSA, and can works as a drop-in replacement for esd. As Compiz is a composit window manager, pulseaudio is a composit sound manager, in that it knows everything about each application's sound. Therefore, its cool features include separate per-application and per-window volumes, on-the-fly sound rerouting, etc. Adobe's Linux Flashplayer group also has a good article on this topic.
9. Internals of the RT Patch can be helpful to understand real-time OS in general and the RT-linux in particular.