A process has a collection of threads (essentially running tasks). This is what the operating system sees, and executes. It basically keeps a long list of threads and rotates through them, giving each a turn to use the CPU(s) for a brief period of time (a time slice). This is where a thread's priority comes into play, along with other factors. The priority helps the scheduler (the part of the OS responsible for handing out time slices) determine which thread should get the next time slice.
A CPU can only do one thing at a time. Therefore, to multitask, the CPU is quickly switched between all active threads on the system. It switches between threads so quickly that it appears multiple processes are running at the exact same time (simultaneously), when in fact they are just taking turns (concurrently). For multi-CPU (multi core) systems, this is still true, except that there are more CPUs available for thread execution, thus allowing some true simultaneous execution instead of just concurrent execution.
When the threads of multiple processes need to use the CPU at the same time, the priority level of each thread is used to help determine which should get the CPU next (which is most important). By temporarily lowering the priority class of overly active background processes, your system is kept responsive even in the face of high CPU loads. Lowering the priority class of a process lowers the priority of all threads in that process. When acting on a process, you are essentially changing the base priority from which the individual priorities of all threads of that process are derived from. In this way, the relative priorities between threads in a process are kept the same.
Windows has a particularly bad problem dealing with threads that decide they want to consume every bit of CPU time they can get their hands on (a CPU bound thread). A single 'CPU bound' thread running at Normal priority can bring an entire single-CPU system to a stall, as demonstrated by our graphical proof of concept below. Yes, it is true - believe it or not! It is this worst case scenario that Process Lasso was originally written to address. By temporarily lowering the priority of the offending process, your PC can be saved from a virtual stall. It was later discovered that, with a few refinements, our algorithm could improve system responsiveness during periods of high CPU loads - in addition to saving the PC from a worst case scenario.
Some schedulers, such as the default one of the Linux kernel, penalize CPU bound processes while rewarding I/O bound processes. Processes is said because unlike the Windows scheduler, linux schedulers handle processes. The Windows scheduler just sees threads, each running at a different priority that is derived from the parent process's priority class. Anyway, this concept of punishing I/O bound processes/threads is similar to what ProBalance effectively does. You see, on Windows *most* threads are I/O bound. They give up their time slices pre-maturely as they enter a wait state for some type of I/O. Sadly, CPU bound (CPU hungry) threads also exist from time to time, and do a real number of the less greedy I/O bound threads.
This does NOT mean you should start reprioritizing all your running processes, ranking them in importance to you. Let our carefully designed ProBalance algorithm do that automatically. Do NOT make manual priority adjustments unless you know what you are doing. It can cause more harm than good. We have written our software to operate safely and effectively in its default configuration, but can't say the same for custom tweaks made by the user.
ProBalance, which stands for Process Balance, is the name of our proprietary algorithm that temporarily adjusts the priority of running processes in an effort to keep your system responsive during high loads.
When there is a high load on the system CPU(s), the responsiveness of the PC can be severely impacted. On a single processor PC, it takes only one CPU hungry thread running at normal priority to bring the entire system to stall. Even high priority threads get totally starved of CPU cycles by a CPU hungry thread running at normal priority. This problem is inherent to the design of the Windows CPU scheduler and general OS architecture. Sure, it seems like such a problem should NOT exist -- but it does, and its easily demonstrated (see 'skeptics' section below).
The casual user will often find their PC responsiveness diminished for brief periods of time (a micro lag). Sometimes this is due to an error occurring in a background process, and other times it is simply because there is such a high load on the CPU. You probably have experienced this before - mouse movement gets jerky and every action is terribly slow.
Process Lasso's ProBalance intelligently lowers the priority class of background processes when they may be interfering with system responsiveness. This doesn't hurt the performance of background processes since they still get a considerable amount of the available CPU time, but it helps the responsiveness of foreground processes tremendously. After all, usually it just takes a few CPU cycles to keep the foreground process responsive. Taking these from background processes, when necessary, is hardly detrimental to them. Also, the adjustment is temporary, so its undone as soon as system conditions change. Process Lasso is designed to be minimally obtrusive, lowering priorities only when appropriate, and making sure that the background processes still perform just fine.
Since processes (and their threads) default to a normal priority, it makes much more sense to lower the priority of offending applications rather than try to raise the priority of everything else! System components and other applications running at a Normal priority will take priority over a 'restrained' process, and thus get the few CPU cycles they need to be responsive. More importantly, testing has showed that restraint via temporarily lowered priorities is vastly superior to any sort of boosting, or raising of priorities.
Since it is a very common 'scheme' used by snake-oil software, foreground boosting should be mentioned. A foreground process is the one that owns the window that has keyboard and mouse focus. This means there is only ever one foreground process at a time. It is essentially the program you are currently working with. Windows already applies foreground boosting by giving the foreground thread longer time slices. Further increasing the priority of the foreground process and/or the specific foreground thread is not effective at all.
Yes, it is. Because of all the multi-tasking we are doing, ProBalance still greatly helps responsiveness even on multi-core CPUs. For example, while building Process Lasso, and having virtual machines running (for testing).. the difference with and without Process Lasso is amazing on an x86 CPU. Multicore PCs are subject to the same sort of problem as single core CPUs, except that it will take a greater number of badly behaved threads to greatly affect system responsiveness. Of course, Process Lasso also offers an assortment of features other than ProBalance that are useful to multicore PC owners.
Multi-core owners will also find our default CPU affinity, watchdog CPU affinity change, and ProBalance CPU affinity change features useful.
Absolutely NOT. Some programs out there encourage you to do just that, but it is dangerous. The authors of these programs are probably not aware of the dangers, or otherwise don't care. While Process Lasso supports setting default (sticky) priorities, it is only meant to be used under certain appropriate circumstances. If you aren't an expert, it is best to let Process Lasso's carefully designed ProBalance algorithm dynamically adjust process priorities as necessary.
With all the various scams out there, such as RAM defragmenters, it is natural for some users to be skeptical. The most common argument comes from those who have overconfidence in the performance of the Windows CPU scheduler. These people believe that *if* the Windows scheduler is written as it should be, then surely normal priority threads can't substantially interfere with the performance of other normal (and above) priority threads. This argument is echoed particularly in non-Windows crowds who haven't experienced the real-world performance of the Windows CPU scheduler.
Most Windows developers will tell you they are disappointed with the Windows CPU scheduler. They will tell you of a time when they had a bug that caused an infinite loop in a normal priority thread running in a process of normal priority class. Much to their dismay, their system was brought to a stall. They've seen this happen. They've stood in disbelief.
The truth is that, on a single CPU system, a single thread of normal priority can bring the entire PC to a near freeze! Even high priority threads can get starved of CPU time by a CPU hungry thread of normal priority. Yes, amazing but true. For multi-CPU systems, the number of threads required to bring the system to a complete stall is equal to the number of CPUs available. Don't believe us? Try our demonstration app, or write your own. Any thread that does nothing but eat up CPU cycles without restraint will demonstrate this phenomenon.
We have developed a 'CPU eater' that you can test Process Lasso with. This CPU Eater creates a handful of threads all running at NORMAL priority. These threads simply use up CPU cycles. Now, if the Windows CPU scheduler behaved like you might expect, other running processes would get enough CPU cycles to remain responsive -- even while this CPU Eater is running in the background. Unfortunately, this isn't the result. Your computer's responsiveness will substantially degrade while the CPU Eater is running! Now, see for yourself ...
This demo defaults to being 'heavy handed', but feel free to lower the thread count. It usually takes far, far fewer to induce an effect than is the default value! Also REMEMBER, the threads created here are background threads. Out of control *foreground* threads cause ever *more harm* since they get considerably longer time slices (depending on scheduler config or OS edition).
NEW: ThreadRacer is a separate benchmarking tool in EARLY ALPHA. See this page for information on it. It's intent is NOT to show the effects of ProBalance, though could be used for that. It is more to show the effects of modern multi-core designs by AMD and Intel, where logical processors share computational resources (e.g. Intel HyperThreading and AMD Bulldozer Core Modules).
Usage instructions for CPU Eater:
Remember, if you don't install Process Lasso the test will simply show the deficiencies in the Windows CPU scheduler. You must install Process Lasso to see the benefits of ProBalance.
After installing Process Lasso, turn OFF ProBalance (or close ProcessLasso AND its core engine ProcessGovernor). Then start the CPU Eater to see how your computer behaves with ProBalance OFF. After completion of this first test, turn ProBalance back ON or restart Process Lasso. Now run the same test again. You will be amazed at the difference, no matter how many cores/CPUs your computer has!
Remember, the threads of the background process the CPU Eater launches are all running at NORMAL priority, and they aren't doing anything besides run in pointless infinite loops. No adjustments are made, we just let Windows handle it. Any application running on your computer has the potential to cause the same effect as our CPU Eater did.
WARNING: As a precaution, we recommend saving all open documents before doing this test. Also, be sure not to reset your computer when your are testing the CPU eater without ProBalance. Your computer will start responding better again in 60 seconds. You agree to accept all risks in running the above test. There are no extraordinary risks, but your system is put to a heavy load, which can cause problems on systems that can not adequately handle heat dissipation. In general, perform this test at your own risk. We must say this, and you must agree if you plan to try this test.The above simple test takes 2 minutes. Give it a try!
This is no trick! You can easily create your own 'CPU eater', or test similar utilities instead of ours. Some CPU Eaters out there raise their priority above Normal, because they don't realize that it only takes Normal priority to 'do the job'. For those, be sure to turn OFF the ProBalance option 'Options / ProBalance Settings / Exclude non-normal priority' or Process Lasso would just ignore them. Normally, Process Lasso leaves high priority processes alone because it assumes they have raised their priority for a good reason. Again, we try to act INTELLIGENTLY, which is the key to making good software. So, create your OWN. An infinite loop in any language, even classical DOS style batch files.
A demonstration of the deficiencies in the Windows scheduler is easy. First, for the sake of simplicity, we'll start describing a system that has a single CPU. The demonstration is easily scaled to multiple cores, but it is easier to describe the concept for a single CPU system.
First, create a process that does nothing but run in an infinite loop, thereby consuming all CPU cycles available to it. We'll call this a 'CPU eater'. Now, launch this process as any other application, at a normal priority class. If the Windows CPU scheduler works as one would expect it to, the performance of other processes on the system, and the foreground process, shouldn't be severely impacted. Unfortunately, you'll find that this single process, running at normal priority, actually so starves other processes of CPU cycles that the system grinds to a near halt -- even termination of the offending process is very difficult. This is true even with the Vista CPU scheduler, despite its improvements.
To scale this argument up to multiple CPUs, simply allow the 'CPU eater' process to have multiple threads, or launch more instances of the CPU eater process. The same effect will be seen.
One reason for this is that the intended proper behavior of a Windows application is not what is seen in the real world. They are meant to do a brief burst of CPU use, then enter wait state. Instead, they often are poorly designed and end up in live-locked and other 100% CPU use situations. It is impossible for Microsoft to know for sure what application really needs that CPU and which doesn't. With a little 'market intelligence', a little logic, and some help from the user Process Lasso's ProBalance can do better -- saving your PC from a total stall or simply increasing responsiveness.
ProBalance yields a benefit on all Windows variants and all CPUs, but it most benefits those CPU architectures that are lean more to the CISC side of the equation. Meaning, they do more per clock cycle, but are clocked at a lower clock speed. This gives them less granularity. We've tested and found it highly effective even on AMD 1055T and 1090T processors. We anticipate ProBalance to be very effective on AMD's new 8120 Bulldozer. It is definitely wonderful on Netbooks and Laptops, where the clock speed is generally lower. Higher clock speed Intel CPUs also benefit, make no mistake about it. Anyway, try for yourself, every system varies - and that is what our CPU Eater is for.
The issues that Process Lasso's ProBalance addresses are well documented throughout the internet. Since we may be perceived to have a bias (though we are biased only towards the truth), we decided to publish some of this third party research. Here are some quick links, and we'll add more soon.
"I should also note that Windows has other scheduling complications, such as "foreground" and "background" tasks [...] However, the bottom line, in my humble opinion, is that the operating system is more concerned in ensuring that a task that is not ready to run does not, than making sure all tasks get a fair shake. [...] We can, however, detect thread and process CPU utilization, and help the operating system to adjust the prioritizations."
-(c) Tim Murgent of TMergent Technologies
"One process that takes up 100% of the CPU time may slow the other applications to snail speed for example, despite the fact that modern OSes use preemptive multitasking."
-(c) Johan De Gelas, AnandTech
"Priorities and their purpose are often poorly understood. Usually the misapprehension exists that if a process is taking a long time to complete then, if anything, its priority should be increased with the intent to make it finish faster. In most cases the CPU is spending near to all of its time executing the process anyway, so increasing the priority is only going to tell the scheduler to do what it is already doing. It may seem paradox but it is in fact more sensible to reduce the priority of the busy process so that the system is prepared to let other processes have some time thus allowing them to remain functional. In most cases other processes will not be using a significant amount of the CPU's time and allowing them to execute when they want to will not slow the busy process by any notable amount. Computer applications simply have to be idle practically all of the time in order for them to react quickly when the user interacts with them. Therefore, allowing a well behaved application to continue to respond in such a way will not take a significant amount of time away from the busy process."
-(c) Peter Ball
To prevent tasks from hogging the CPU and thus starving other tasks that need CPU access, the Linux 2.6 scheduler can dynamically alter a task's priority. It does so by penalizing tasks that are bound to a CPU and rewarding tasks that are I/O bound. I/O-bound tasks commonly use the CPU to set up an I/O and then sleep awaiting the completion of the I/O. This type of behavior gives other tasks access to the CPU.
Process Lasso was created with one primary rule 'Do no harm'. Therefore, its ProBalance algorithm only makes changes believed to be entirely safe. Further, when a change is needed, it makes the most minimal one possible. We look at this as a conservative approach. We've seen other software not be so kind, believe it or not. Beware of gimmicks out there that boost priorities carelessly. Many of these gimmicks boost the foreground process priority to High, which is not only unhelpful, but is also unsafe. Try those utilities with our demo - or write your own CPU Eater if you don't trust ours, it couldn't be more simple to create. In C, a 'while(1);' (infinite loop) is all it takes...
When you go to make manual changes to certain system processes, or enable certain features of Process Lasso, warnings are shown that inform you of possible risks. However, we can't possibly account for every conceivable user induced error and/or software environment, so its possible custom modifications to Process Lasso's configuration could cause unforeseen negative consequences. We furthermore can't warn of all possible risks, so we simply recommend NOT changing the default settings unless you are an expert. Carelessly changing the priority class of processes is potentially determinantal to the stability of your PC. We recommend you just let Process Lasso's ProBalance algorithm do its job, unless you know what you are doing.
Since Process Lasso allows such advanced configuration tweaks, we must issue a legal warning at install (a EULA). As always, you assume all risk and liability for any damages, tangible or intangible, resulting from the use or misuse of our software. If you do not agree with that, then we can not allow use of our software. The full EULA is presented prior to install. If you can not read AND agree to it, then you must cancel the install.