You can do something about this by defining the CPU affinity for this process, as in the CPUs it will be allowed to run on. In Task Manager, click the Process tab, right-click the process, select 'Set Affinity' and clear all but one of the CPU boxes. On a dual-core processor, this means the process will now only run on one of your cores. Even if you leave it at a normal priority, the program still shouldn't grab all your CPU time, leaving you able to do other things.
It's also possible to launch a program with a given affinity setting, again thanks to the very useful 'start. exe' command, although you do have to calculate an affinity mask first. Essentially, the first core has a value of 1, the second 2, the third (if you've a quad-core system), 4, and the fourth, 8.
Decide which cores you'd like the process to run on, then add those values together to produce the affinity mask: just core 1 and it would be 1, cores 1 and 3 would be 5, and so on. Convert values over 9 to hex, then specify them in your shortcut like this, replacing 'm' with your affinity mask: cmd.exe /c START AFFINITY m c:\path\app.exe.
This is a useful technique to apply occasionally, if there's a specific program that you don't want to grab all your CPU time, but be careful. Generally, the less leeway you give to Windows own thread scheduler, the more inefficiently your PC will run. Just like priority boosting, it's best to use CPU affinity tweaks sparingly.
System resources
Controlling how your processes access the CPU is an excellent first step in optimising a PC, but there's plenty more work to do. And learning something about the limitations of your system resources can be particularly useful, at least for 32-bit Windows users. (If you're using 64-bit Windows this next section won't apply to you, sorry.) 32-bit Windows allocates 2GB of virtual address space to each process you run.
The Windows kernel also only gets 2GB to store everything – kernel code, drivers, DLLs and all the components it needs to keep your system running – so all resources are strictly rationed. Virtual memory allocations by kernel components like DLLs are taken from something called the 'paged pool' and on a 2GB Windows XP PC, that defaults to a maximum of 360MB in size.
Drivers often require memory that is guaranteed never to be paged to disk and that's taken from the 'nonpaged pool' (which defaults to a maximum 262MB on a 2GB XP PC).
Windows XP doesn't let these pools grow to meet demand, so if a buggy driver grabs all the pool memory, odd things begin to happen: error messages, network failures, hangs and more. Windows XP users can make the situation even worse if their PCs have 4GB of RAM and they use the '/3GB' switch to try and give applications access to more memory (see http://support. microsoft.com/ kb/833721 for more information). This squeezes Windows own address space down to a mere 1GB, making resources drop still further.
The maximum non-paged pool falls from 285 to 154MB and system page table entries (a resource used to map virtual to physical memory, see www.tinyurl.com/ 6j5wmg) plummets from 106,000 to around 15,000. If you've used the '/3GB' switch and your PC is now unstable, that may be why. Remove it and see what happens.
32-bit Windows Vista improves on this situation in many ways. It can now dynamically allocate new memory if either pool needs it, so your system will keep running. Still, if you've a resource leak – a process that keeps grabbing objects and doesn't release them – then even Vista will run into problems eventually. That's why everyone can benefit from monitoring their PC's resource use.
