A number of people called bs on my last post, some publicly, some privately. So I thought I'd explain why this is possible and how the system really responds under load in my own tests.


ULE uses two basic metrics to determine how a thread is run. One is % cpu used over the last few seconds. The other metric is time voluntarily slept over time ran. This does not include time waiting for the run queue. This is the interactivity score. The interactivity score is actually annoyingly not a simple fraction because we can't do floating point math in the kernel. Both metrics use a gradual decay algorithm that incorporates past history to a lesser degree than current history.

A thread is considered interactive if it sleeps a sufficiently long time on average compared to the amount of time it runs. Interactive threads have priorities greater than non-interactive threads. They are just below real-time threads. The priority of the thread is basically the interactivity score scaled evenly across the range of possible interactive priorities. Interactive threads are always run in strict priority order and are selected before non-interactive threads.

Non-interactive threads get priorities according to the %cpu used, modified by nice. They are put onto a calender-queue like mechanism that ensures fairness as I have discussed before. They are run as their queue slot advances to the head of the queue.

So really, you could have 1,000 threads running and as long as your shell or mozilla or whatever was considered interactive, they'd have no latency. In fact, even as interactive tasks they may be alloted more CPU time than normal timeshare tasks who are competing fairly for the remainder of the cpu. This does open up the possibility for attacks that sleep for exactly the amount required to be considered interactive, however, since this queue is run in interact score order, shells and likely even X11 would not suffer as a result.

So you can see that the slashdot post is entirely feasible. On my single processor 1.6ghz PentiumM with 2gb of ram and a single laptop ide drive I can run 64 compiles and browse the web etc without any jitter. I can play movies from the dvd drive with no skipping or jitter. However, if I play movies off of the hard drive they compete for io ops with the compiles. In this case, there is certainly skipping.

FreeBSD is certainly not a desktop panacea where nothing ever skips and your old crappy hardware performs as if it's brand new. I don't claim that. I'm certainly able to reproduce skipping due to disk latency under high load. However, it is entirely feasible, and reproduced by many people, that ULE maintains excellent interactive performance in the face of many cpu hogs.