Hi all,
ProcessTamer does a good job in handling one of the bottlenecks of current computers, which is access to the CPU. It does so by changing the priorities of the processes. This works because Windows incorporates a priority-based queue for CPU access.
There's another important bottleneck in present-day computers: access to the disk(s). Windows doesn't include a priority-based queue for disk access. It just has a first come - first served queue. This can allow a low-priority process to virtually hang a computer.
Imagine the following situation: a certain process needs to make many, very frequent disk accesses. An example could be the disk scanning component of an anti-virus package, which has to access all the files in the disk to do its job. You set this process to low priority, in an attempt to make it run in the background, without disturbing your normal use of the computer. However, whenever the higher-priority processes leave a bit of free CPU time, this low-priority process is allowed to run. Even if it runs for a short time, it immediately fills the disk queue with a lot of access requests. Now, one of your higher-priority process runs again, and needs to make a single disk access. Since the disk queue is full of requests from the low-priority process, and since the disk is a relatively slow component, your high-priority process will have to wait until all the requests from the low-priority one are served. While the high-priority process waits to get its disk access served, the low-priority process gets to run a tiny bit of time again, and places a further lot of requests in the disk queue... The net effect is that the high-priority process is almost completely blocked by the low-priority one.
Situations like this are not infrequent. I think that some present-day disk scanners from anti-virus packages are already designed so as to prevent this from happening (e.g. by self-limiting the number of consecutive disk access requests that they make, and waiting until all of them are served before making new ones). But most other programs are not designed in that way. And a program that runs astray due to some bug can also start placing an inordinate number of requests in the disk queue. I've run into situations like this from time to time, and in some cases the only way to solve the problem was to press the reset button and then reboot, because even the task manager would take an inordinate amount of time to start, and therefore I was unable to kill the offending process.
This kind of problem can't be solved by changing process priorities: As I explained, even a low-priority process can effectively block high-priority ones. I think that the only way to handle it is to temporarily suspend the offending process, based on the number of disk requests that it makes. The best rules for doing this will probably have to be learned by experimenting. Certainly, it will be desirable to allow the user to explicitly exclude some processes from this kind of taming.
I don't know how hard it is to implement a strategy of this kind, because it means adding a taming philosophy that is very different from the one currently used by ProcessTamer. But it would certainly be a very useful addition.
On a side note, the fact that Windows still doesn't include a prioritized queue for disk access says a lot about Microsoft's own priorities in software development.
And on another side note, thanks a lot to Mouser for making ProcessTamer, and other useful programs, available to all of us.
ProcessTamer does a good job in handling one of the bottlenecks of current computers, which is access to the CPU. It does so by changing the priorities of the processes. This works because Windows incorporates a priority-based queue for CPU access.
There's another important bottleneck in present-day computers: access to the disk(s). Windows doesn't include a priority-based queue for disk access. It just has a first come - first served queue. This can allow a low-priority process to virtually hang a computer.
Imagine the following situation: a certain process needs to make many, very frequent disk accesses. An example could be the disk scanning component of an anti-virus package, which has to access all the files in the disk to do its job. You set this process to low priority, in an attempt to make it run in the background, without disturbing your normal use of the computer. However, whenever the higher-priority processes leave a bit of free CPU time, this low-priority process is allowed to run. Even if it runs for a short time, it immediately fills the disk queue with a lot of access requests. Now, one of your higher-priority process runs again, and needs to make a single disk access. Since the disk queue is full of requests from the low-priority process, and since the disk is a relatively slow component, your high-priority process will have to wait until all the requests from the low-priority one are served. While the high-priority process waits to get its disk access served, the low-priority process gets to run a tiny bit of time again, and places a further lot of requests in the disk queue... The net effect is that the high-priority process is almost completely blocked by the low-priority one.
Situations like this are not infrequent. I think that some present-day disk scanners from anti-virus packages are already designed so as to prevent this from happening (e.g. by self-limiting the number of consecutive disk access requests that they make, and waiting until all of them are served before making new ones). But most other programs are not designed in that way. And a program that runs astray due to some bug can also start placing an inordinate number of requests in the disk queue. I've run into situations like this from time to time, and in some cases the only way to solve the problem was to press the reset button and then reboot, because even the task manager would take an inordinate amount of time to start, and therefore I was unable to kill the offending process.
This kind of problem can't be solved by changing process priorities: As I explained, even a low-priority process can effectively block high-priority ones. I think that the only way to handle it is to temporarily suspend the offending process, based on the number of disk requests that it makes. The best rules for doing this will probably have to be learned by experimenting. Certainly, it will be desirable to allow the user to explicitly exclude some processes from this kind of taming.
I don't know how hard it is to implement a strategy of this kind, because it means adding a taming philosophy that is very different from the one currently used by ProcessTamer. But it would certainly be a very useful addition.
On a side note, the fact that Windows still doesn't include a prioritized queue for disk access says a lot about Microsoft's own priorities in software development.
And on another side note, thanks a lot to Mouser for making ProcessTamer, and other useful programs, available to all of us.
Thanks yksysks!
- carpe noctem