|
![[Jason's Home Page]](../BackTo.jpg) |
|
|
Idleize is a simple utility which allows you to easily run background tasks during idle time only. It is ideal for running SETI@home, as well as other background tasks such as hardware simulations, compiler test suites, computer graphics rendering, and so on.
Skip to the bottom of this page for the current version and history of changes.
Porting idleize to other UNIX systems is quite easy. All you need to provide is the system-specific code to get the current CPU load average and number of processors. Take a look at the source code of the appropriate machine-specific module in top if you don't know where to start. If you do port idleize to another system, please email me the changes so that I can update the distribution and others can benefit from your work. Your name will be mentioned with your updates. Also, it would be good if you could provide a pre-compiled binary.
idleize - run a subprocess during idle time only
idleize [options] command args
idleize can be used to run a subprocess during idle time only. This is useful if you want to use idle time to run background tasks, but do not want them reducing your system's performance when you are using it normally.
Simply running the background task at low priority doesn't have quite the same effect, since issues such as cache competition will reduce your overall system performance even if the task is at nice level 19. The performance loss is small but measurable (it can be as much as 10% on some systems).
idleize uses a screensaver-style algorithm to control the subprocess. The system's CPU load average is measured every few seconds. If the system has been idle for a certain amount of time, then the subprocess is run. As soon as the system becomes active again, the subprocess is stopped.
-l load%
The system load percentage used to define "idleness" can be supplied using the -l option. The default is 10%. This should be set high enough that standard background daemons such as sendmail do not cause the subprocess to be stopped unnecessarily, but low enough that any genuine user activity causes the subprocess to stop immediately.
If you want to let the subprocess keep running while you're doing mildly CPU-intensive tasks like browsing the web, then try using a setting of around 50% (more for older/slower machines). Tasks such as basic text editing should fall below the default 10% threshold.
As a special case, the default load% on MacOS X is 50% to account for the more CPU-intensive user interface. Also note that on MacOS X if any Classic applications are running they will consume significant CPU time even when they are just sitting in the background, so the system load is unlikely to drop low enough to be considered idle.
-t time
The amount of idle time to wait before starting the subprocess can be supplied with the -t option, a number of seconds. The default is 300, which is 5 minutes. This should be set long enough to avoid unnecessary starting and stopping of the subprocess, but short enough that the subprocess does get run when suitable so that idle time is not wasted.
Reducing the idle time setting much below 3 minutes is usually not worthwhile due to the way the load average is calculated in the kernel (it takes a couple of minutes for the load average to subside after a period of intense activity, so even at a setting of zero it would have to wait those couple of minutes for the load average to drop).
-b batt%
For laptops, you may control whether the subprocess will be run when the battery is being used, or more specifically when the battery level goes below a desired level. The default is 100%, meaning that the subprocess will not be run unless the system is connected to mains power and the battery has been fully charged. This option is currently only supported on MacOS X.
-k
The subprocess can either be stopped and restarted using exec() and kill() or can be run once then controlled using SIGSTOP/SIGCONT to suspend and resume execution. Using SIGSTOP/SIGCONT is the default, but you can use the -k option to get exec/kill behavior. You should only use -k on programs that periodically save their state to disk and can startup more quickly from that state than from being swapped out to disk. One such program is setiathome.
-r
If the subprocess exits (finishes), then normally idleize will exit too. In cases where you want to restart the subprocess again if it exits, you can use the -r option. The timer is reset when the subprocess exits, so it won't be restarted for a few minutes. One common situation where this is useful is setiathome, which only exits on error conditions like the SETI network servers being too busy and refusing connections.
-v
Print the version number and exit.
idleize -k -r setiathome -email >/dev/null 2>&1
On a multiprocessor system things are not handled in the way some people might expect, where the subprocess would get run on an idle CPU if your workload doesn't need all the CPUs in the system. Having the subprocess running on the idle CPU wouldn't cause any cache competition in most multiprocessor designs, but it would use some of the available memory bandwidth. So there would still be a measurable slowdown caused by running the background task.
Instead, all the programs under idleize control will be stopped when the system load exceeds numcpus + load%, so that the entire machine's memory bandwidth is available to the user. The background tasks will only be restarted when the system becomes idle across all CPU's. This works very well in practice, and is usually what users want once they think about the memory bandwidth issues.
If you want the behavior described in the first paragraph (run the background task on an idle CPU if there is one), then you will probably be satisfied with simply running the background tasks at low priority and not under idleize control. The performance difference between these two alternatives is minimal.
Since idleize doesn't know whether the subprocess is a multithreaded (parallel, multi-CPU) program or just a single threaded program, it is assumed that all CPU's are used to run tasks during idle time. If you only run one single threaded task under idleize control on a multiprocessor system, it will not be stopped unless you use all the processors to drive the load up above numcpus + load%. You can work around this by specifying a negative load% (eg: -90% on a dual processor system running a single background task). This makes things work correctly (2 + -0.90 = 1.10). Of course, if you have a multiprocessor system, you probably want to use all the processors to run background tasks, which is exactly what idleize was designed for.
Both idleize itself and the subprocess are automatically run at the lowest CPU priority (maximum nice level), and will ignore hangup (HUP) signals.
Sending a USR1 signal to idleize will force the subprocess to start immediately, and sending a USR2 signal will force the subprocess to stop immediately.
Spending time "tweaking" the options to achieve an "optimal" behavior for your situation is not recommended. You are very unlikely to achieve significant gains. Instead, try to see the big picture, and use the defaults.
nice(1), priocntl(1), nohup(1), top(1).
Jason Patterson (jason@pattosoft.com.au)
http://www.pattosoft.com.au/idleize
1.0 - Jun 1999 - Original version.
1.0a - Jul 1999 - Ported to old Solaris versions (pre-7).
1.0b - Aug 1999 - Ported to SGI IRIX 6.x.
1.1 - Sep 1999 - Bug fix for MP subprocess restart.
1.1a - Oct 2000 - Ported to MacOS X.
1.1b - Nov 2000 - Ported to Linux.
1.1c - Jun 2001 - Ported to Tru64 5.x, by Thorsten Koch.
1.2 - Sep 2002 - Bug fix for MacOS X 10.2.
1.3 - Nov 2002 - Changed default idleness on MacOS X to 30% (Classic apps are now rare).
2.0 - Nov 2002 - New battery option (-b) for laptops. New version reporting option (-v). Changed default idleness on MacOS X to 50% to allow for old/slow machines. Faster subprocess stop on multiprocessors. Bug fix for better handling of system-wide sleep.
Copyright © 1999 Jason Patterson. Last Updated:
