> Why is this better than nice-19?
It totally removes the job from the OS's run queue, so it takes _no_ CPU
time when the load crosses a threshold. When the load drops below a second
threshold, it puts it back on. So, if your loadwatched job holds the load
at 1.0 normally, you set the highpoint for something like 1.15. When
anything significant starts, the load goes over 1.15, and the loadwatched
job totally stops (with SIGSTOP). Whatever loaded the system will
presumably now keep the load over the second point, say 0.15, and it will
not have the loadwatched job stealing any cycles from it. Once the load
drops below 0.15, the loadwatched job is sent a SIGCONT.
As mentioned elsewhere in this thread, a nice 19 job still gets 5% of the
CPU. And, if that job is using resources like lots of memory or doing I/O,
it can have a disproportional impact on the system. Even for a CPU bound
job like rc5des, some people can notice it running at nice 19 because of
slightly slower interactive performance. If you're one of them, loadwatch
works pretty nicely for getting rid of that small lag.
Later,
Dale
-- +-------------------- finger for pgp public key ---------------------+ | Dale E. Martin | Clifton Labs, Inc. | Senior Computer Engineer | | dmartin@clifton-labs.com | http://www.clifton-labs.com | +----------------------------------------------------------------------+- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/