No, the process in the state I describe will be counted against the load. Part of the problem is that these stats must be computed very quickly and the process table is the only structure referenced for the computation of the load. Whether or not to count it depends on its wait priority and this is too simple minded to get it right all the time. Other short cuts are taken during the computation of the load averages. It does not have all of the observations over the past 15 minutes available. So a moving average is computed (but without using floating point arithmetic which is considered to be too slow). Still it is generally a very useful set of statistics.

My descriptions are not based on the most recent source code and its possible that some stuff has changed. When I looked at the code there was no halting or fiddling with the frequency. I hoped to dance around this by presenting a description of a very simple fictional system containing only a single cpu. I can't imagine an OS halting a single cpu unless it was for keeps. Underclocking itself is certainly possible though.

Just to be sure, are you telling a major page fault do not necessarily put the affected thread in the i/o wait queue ? Seems quite odd to me.
Also, are you sure the process table is walked to compute the load ? My understanding is the cpu partition (aka processor set) tables are used instead.

About CPU halting, here is an interesting blog:
The most executed code in Solaris ... the cpu idle loop : Bill Holler's blog

Not at all. Again, only the process table is scanned.

Is the process running... if so it counts.
Does the process want a cpu...if so it counts.
Is the process expected to want a cpu very soon...if so it counts.

The sum of these counts is called nrun and it is then used to update the avenrun array.

The i/o wait queue has no influence in this calculation.

In the case of a process awaiting the arrival of a page, it seems to me to make good sense to count it. In the case a process waiting for a mag tape to rewind, it seems to me to not be good sense to count it. However both are counted in nrun.

That 3rd category is processes sleeping with a priority below PZERO. This is same condition that keeps a process alive beyond a "kill -9". A process waiting for a read() system call to complete would not be counted. A process waiting a disk buffer because it is in the middle of a mkdir() call is counted.

Sorry to disagree but on what Solaris source code release are you basing these statements ?

I see no reference to the process table in the OpenSolaris published one
Cross Reference: /onnv/onnv-gate/usr/src/uts/common/os/clock.c
and I'm wondering if that would work anyway. A single process can easily generate a much higher load than 1. According to the method you describe, it would only show as 1. Moreover, walking the process table which can contains thousands of entries would be less efficient than using the processor sets run queue sizes as I understand the code is actually doing.

As I said, "My descriptions are not based on the most recent source code and its possible that some stuff has changed."

If you disagree with the algorithm I gave, please give us the algorithm that you think is being used.

Okay, so here is my understanding of what is used based on what I can read in the kernel source code.

At every clock interrupt (each 10 ms by default) Solaris walk the kernel per cpu (or per cpu partition since supported) statistics, not the process table. The run queues size and running lightweight processes count are summed to compute the instantaneous load. The i/o wait queue size is not used to compute this load. From these values are computed three moving decayed averages that are available in the avenrun kernel variable and through the kstat interface.

As far as I know, this has been true at least in the last decade. I'm pretty sure Solaris 2.6 already did it that way.

I'm not aware of major faulted threads being accounted as running ones but I'm not denying that might have been implemented with Solaris, I'm just skeptical.

That said, I'm puzzled by the fact you insist challenging/ignoring some of my points given the fact you are one of the most authoritative and reliable poster in this very forum. I would really appreciate if you tell what precise Solaris release you are basing your statements on.