Bug 122923

When a background process that is CPU intensive is 'renice'd to 19, it will still affect foreground processes (such as watching a movie with vlc) such that 'stuttering' or obvious lapses in process scheduling can easily be observed.  Removing the background process entirely alleviates the 'intermittent response' or 'stuttering' problem.  In its worst state the 'stuttering' seems to allow about 1/2 second 'bursts' of CPU for the foreground, then the background process, then the foreground again, when CPU utilization in the foreground approaches the 100% mark (like decoding an H.264 movie).

Using 'idprio' to TRULY move the background process into the background can make it possible to leave the background process running and NOT cause significant performance problems in the foreground.  However, the behavior I describe here did NOT exist in 6.3 and should not require this kind of workaround.

In my search for similar bug reports, I found a behavior described in 'ports/118645' where mouse response was 'intermittent' or 'stuttering' while a background process used a lot of CPU.  I have also observed this particular mouse behavior on rare occasions, once precedeeding a system crash (see kern/122615).

Fix: 

A workaround can be achieved by using 'idprio' to move the background process into the idle priority class as described above.  This appears to have the same effect on the process that 'renice 19' had in 6.3 .
How-To-Repeat: a) run a CPU-intensive process with 'nice 19' (such as 'dnetc' from ports), one that does not already move itself into an 'idle priority' class.
b) run the 'XAnalogTV' x screensaver under X11.  Observe intermittent display updates.  [Alternately play a video with vlc that requires >50% cpu to decode, ideally with divx or h.264 encoding]
c) use 'idprio' to move the dnetc process into one of the lowest possible priority classes (idle 30)
d) run the 'XAnalogTV' screensaver (or video) again