n2k14 hackathon report: kettenis@ on DRM, multiprocessor scalability, and making dump(8) work again on sun4v

After some excellent tramping on New Zealands South Island, I arrived in Dunedin without any traces of a jetlag. As usual I did have some vague plans.

I brought the ThinkPad T400 that somebody recently donated because it has both inteldrm(4) and radeondrm(4). And together with Jonathan Gray (jsg@) I did end up doing some code cleanups.

But most of the hackathon I spent working with David Gwynne (dlg@) on some small steps on the long road to making OpenBSD scalable on MP systems.

Last november I committed some initial diffs that allow us to run interrupt handlers without holding the kernel lock. This has already been used sucessfully within the audio subsystem, but during the hackathon we looked at what work still needs to be done in the network and scsi subsystems.

We quickly identified some sparc64 MD bits that still needed some work and I started hacking on those. I made "mpsafe" interrupts work on the remaining sparc64 PCI host bridges and fixed the sparc64 iommu code to be "mpsafe". The changes I made there are actually very useful because they remove some memory allocations out of the disk I/O path; very useful if you're out of memory and want to swap...

David and I also discussed various APIs for doing atomic operations and memory barriers that are needed to do lockless programming in the kernel. We settled on the API used by Solaris and NetBSD, and I sucessfully tricked him into implementing the chosen API for sparc64!

Then Henning Brauer (henning@) reminded me that he ran into problems with dump(8) on sun4v guest domains. It turned out to be easy to reproduce, but a lot harder to fix. Eventually I found the problem. My vdsk(4) code was making the assumption that the buffers used in I/O requests were page aligned. Turns out that is mostly true, but that access to the "raw" disk device passes buffers down directly from userland. Guess what dump(8) uses! On the other end, the vdsp(4) driver had some error paths that were not very robust. So I fixed those as well. And of course looking closely at code always reveals some other problems as well, so I ended up making a few commits to vdsk(4) and vdsp(4). So sun4v support is in much better shape now.