RealtimeKit and the audio problem

This is a good discussion.

I agree that compute intensive, yet time sensitive, apps could "yield often" as you describe. Indeed, coop_poll relies on that too.

A couple of points about such yielding:

1) if it so, then the difference between SCHED_RR and SCHED_FIFO is moot, as the application would be setting the quantum as you observe;

2) coop_poll allows such applications to yield more intelligently, by providing the application with direct information about when it should yield.

Point #2 can mean far fewer yields/context switches, hence lower overhead and better responsiveness. In the paper we show that a purely periodic approach (i.e. yield often regardless of whether it is absolutely needed or not) has measurably worse performance; an experiment in the paper show this where coop_poll responsiveness is ~1ms vs periodic approach at ~5ms, while at the same time coop_poll has almost 5x fewer context switches. This is part of why I think SCHED_FIFO doesn't cut it. The issue is to divide time between short rapid timeslices for time sensitive events, and longer timeslices for longer, less time sensitive computations. coop_poll can and does do this. With SCHED_FIFO, a similar result could be achieved by dividing the application threads in a way that ensures that any heavy computation runs only in separate, non real-time threads, while time-sensitive actions are within a SCHED_FIFO thread. I think having fewer threads is architecturally preferable, but I guess it is a matter of personal taste.

Also, I'd point out that the share of CPU, e.g. with Pulse, is not that big an issue. Fair share schedulers support weighted fair sharing--e.g. in Linux, the nice value is translated into the fairshare weight (both with CFS and our scheduler). Thus giving a 'nice boost' to Pulse, and other servers such as the X11 server, is safe and arguably sensible thing to do.

-- Buck