I find your comment intriguing but somewhat puzzling. In my tests, I've never had trouble achieving ~1ms scheduling accuracy with stock kernels (at least since the soft real-time patches were first merged years ago), and -rt kernels are substantially better (~10us?). That's using SCHED_FIFO though, of course. Getting precisely timed wakeups out of the kernel *has* historically required somewhat obscure APIs, but this has gotten much easier over time (from /dev/rtc to real-time signals to timerfd to now, finally, hrtimer-enabled poll).
I can't seem to get your paper, but if the graphs for "RT" in your slides were generated using a real high-precision wakeup mechanism then I'm very surprised. Can you confirm what you used? IIRC for 2.6.25 you still have to use a rather complex signal-based approach.
Still, getting RT-like behavior without SCHED_FIFO is quite excellent. Is the idea that coop_poll() is a poll-like syscall with two additional properties: 1) it uses hrtimers for precise wakeups, 2) when a wakeup does occur, the process gets preferential treatment in waking up *immediately*, so long as this doesn't produce unfairness over the long term?