Last Summer (I guess that would be Winter in the Southern Hemisphere) I was attempting to apply RCU to the signal-delivery code in the Linux kernel in order to reduce its realtime latency. The first prototype definitely greatly reduced latency, but it also introduced a number of glaring races. Despite the glaring race, the code passed LTP and kernbench. Clearly, better tests were called for. Yes, 10,000 eye see through all bugs, and Oleg's pair of eyes were being quite effective, but there is also a place for a good set of software tests. I decided to use the technique that my RCU co-inventor, Jack Slingwine, had used some years back. His approach was to offset the racing operations by varying numbers of microseconds in the hope of catching all races. However, CPUs are much faster than in the early 1990s, so microseconds no longer cut it. Instead, nanoseconds are needed. I needed tests that "steamrollered" over the race, nanoseconds at a time. This paper will describe how I constructed my steamroller and how it located bugs that were invisible to other testing techniques. See http://www.rdrop.com/users/paulmck for a partial list of prior papers and presentations. I have presented at both linux.conf.au and OLS, so have some open-source presentation experience.
Paul E. McKenney
Paul E. McKenney is a distinguished engineer at IBM and has worked on SMP, NUMA, and RCU algorithms for longer than he cares to admit. Prior to that, he worked on packet-radio and Internet protocols (but long before the Internet became popular), system administration, realtime systems, and even business applications. His hobbies include running and the usual house-wife-and-kids habit.