Hence the maximum time after which the job is run anyway. The main idea being
that in the common desktop machine case you can prevent cron jobs executing
at an inconvenient time. "this job should run at midnight but if the machine
is still busy then, run it any time up to 3am, if it's still busy at 3am
just run it anyway" is an example of what I've already said above.
It's not something I'd even consider on any of my servers. I _know_ exactly
when I want jobs to run. I'd rather tell people "the performance will be bad
at time X" than tell the job not to run when the server is loaded. But in the
home machine case there is obviously some case for it. The other alternative
(and the only reason this thread could even be possibly on-topic) is to run
CPU-intensive console games and CD burners as RT tasks and try to prevent
other tasks affecting them. But if the tasks contains lots of disk I/O even
if it's niced it may still have to much effect and wreck the CD.
David.
-
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/