The single most important piece of information processed by top is the measure of a process's percentage cpu utilization, known as percent cpu. Although top is perfectly capable of display and sorting on a variety of information, by default it sorts by percent cpu. The reason for this is that most people use top to find out what the cpu is doing, or more specifically which process is hogging the cpu. Percent cpu readily reveals this information.

But how exactly is this measured? Since the early days of BSD, the percent cpu utilization of each process was calculated by the kernel and saved along with other process information in what's called the proc structure. The kernel maintains an array of proc structures to track its processes. The ps command and, in some cases, top simply display this value as a true representation of process utilization. Unfortunately, that isn't the whole truth.

You see, the only reason the kernel cares about this number is so that it can provide equitable access to the cpu. If a process is using too much cpu and there are other processes waiting to run, then the kernel will want to ensure that each process gets a fair shot at running. So it calculates a figure that takes recent history in to account; a decaying average of the true cpu utilization for a process. In most BSD-derived systems, for example, the average is decayed so that 95% of a process's utilization from 60 seconds ago is no longer counted (but 5% is). If a process begins to accumulate a high average percentage then it has been sustaining such high use for at least 30 seconds, and probably longer. A process with a high average is likely a cpu hog and should be given lower priority when being scheduled for the cpu. In Unix, the decaying average is used when making scheduling decisions (see footnote). You can see how this number behaves over time. Start an infinite loop on an otherwise idle system (my favorite is "while true; do true; done"). Then watch the %cpu figure in the output of ps. At first it will be quite low. In fact, it will take about 30 seconds before the percentage reaches 50. It won't get over 90% until about 55 seconds, and it won't reach 99% or 100% until a full minute after you start the loop. This is because it is still giving weight to the idleness of the process from a full minute in the past.

The decaying average is helpful to the kernel, and it may be helpful to someone who wants to get a single snapshot of the system with ps. But top is intended to provide information about what is happening with the system right now, not a minute ago. I think it is misleading for top to show this decaying average as percent cpu, as it doesn't always provide an accurate picture of the moment. Some of the ports for top now calculate this percentage from other information rather than simply parroting what the kernel has done. This provides a better picture of what happened over the past 5 seconds, while ignoring information that the kernel scheduler will use. The calculation is simple. A process's total accumulated cpu time is also tracked in the proc structure, and is shown in the column labeled time. To calculate percent cpu, top will sample and remember every process's cpu time. At the next update, it will again sample cpu time, calculate the difference from the last reading, divide by the elapsed time between the samples, then multiply by 100 to convert to a percentage (multiprocessor systems complicate this, and we will get to that case next). This provides an accurate measurement of cpu utilization between updates, but it is not a decaying average. If you are on a system where top performs this calculation, then start your infinite loop again and run top. You will see that within two updates the process is at or near 100% (assuming your system is otherwise idle and that there is only one processor). There is one downside to this method: top has to take two samples before it can display percent cpu. You may notice on such systems that it takes about a second for top to display its first screen of data. This is entirely due to the need for recording two samples before calculating percent cpu.

There are cases where top will only show 50%, 25%, or even a lower figure for a looping process on an otherwise idle system. If you are on a system that has more than one cpu, top will probably display cpu utilization as a percentage of the total available cpu. So if you have two processors, a single process can only use one of them and will only show 50%. Likewise on a 4-processor system your infinite loop will only show 25%. However, a process with multiple threads will be able to utilize more than one processor simultaneously. Top will reflect such utilization with higher percentages. Think of it as a percentage of all available cpu cycles across all processors.

While continuing development for top, I plan to implement direct calculation of percent cpu in as many ports of top as I can, as I believe it provides a better picture of system activity. I am interested in feedback from the user community on this matter. What do you think?

Weighted CPU

While we are on the subject of percent cpu, we must mention something called weighted cpu. This is a bit of an embarrassment to me, but I feel that some sort of clarification is long past due. Top was originally written for BSD 4.1, which tracked percent cpu pretty much as described here. However, the scheduler would apply an additional calculation to that number before using it to influence scheduling. The result was known as weighted cpu percent, and was also reflected in the source for ps. I dutifully followed suit and, in that early version, displayed raw cpu and weighted cpu in two columns side-by-side. As Unix grew, mutated, and developed, scheduling algorithms were changed and methods altered. Percent cpu is an easy measure to understand and it has significance to you and me, but the intent and meaning of weighted cpu became lost. Most Unix systems no longer used this calculation, preferring improved scheduling algorithms that no longer needed it. Nonetheless, when top was ported to these systems by well intentioned individuals, they copied the code for calculating weighted cpu. I think it is fair to say that at this point in time the number no longer has any meaning on any modern Unix system. Even the ps version of BSD calculates and displays something called weighted cpu, but that number really has no relevance to scheduling or anything that goes on in the kernel. Right now I consider weighted cpu nothing more than a waste of valuable screen space. In future versions of top you may no longer see that number.

Footnote

In actuality, BSD systems (starting with version 4.3) no longer use a traditional decaying average in their scheduling algorithms, and they only track the number to keep ps happy. The BSD scheduler instead uses a formula that decays cpu utilization by a factor of the load average.