Calculate 'percent_cpu' relative to a single processor on Solaris

[Low-power]

The Solaris procfs reports pr_pctcpu relative to all on-line processors on the system (see https://code.illumos.org/plugins/gitiles/illumos-gate/+/refs/heads/master/usr/src/uts/common/fs/proc/prsubr.c, function prgetpctcpu), while htop's percent_cpu is based on a single processor; this caused the processor usage off processes be under-reported on SMP systems.

For example, a process with 4 busy threads, running on a Solaris system with at least 4 processors, I would expect the %CPU values be close to 400% and 100% for process and each thread display respectively.

[BenBE]

Please note https://docs.oracle.com/cd/E23824_01/html/821-1473/proc-4.html

pr_pctcpu and pr_pctmem are 16-bit binary fractions in the range 0.0 to 1.0 with the binary point to the right of the high-order bit (1.0 == 0x8000). pr_pctcpu is the summation over all lwps in the process.

pr_lwp contains the ps(1) information for the representative lwp. If the process is a zombie, pr_nlwp, pr_nzomb, and pr_lwp.pr_lwpid are zero and the other fields of pr_lwp are undefined

So either the reported pr_pctcpu is wrong, or the base for "% of recent CPU time" is overall CPU time available, not per-core, in which case instead of scaling arbitrarily it's better to just add up all of the LWPs CPU times (which as you stated) should yield the correct result.

[Low-power]

I has did a test where a busy-looping thread in a testing process never have its %CPU go beyond 25% on a 4-way SMP system. So scaling it for each LWP is still required. Of course unless we decided to drop pr_pctcpu completely and calculate percent_cpu manually from pr_time.

[BenBE]

IIRC this is the approach used on Linux: Calculating the percentage based on available CPU time for each process. Can you estimate how much change this causes down the line? For a first fix I'd go with this simpler approach of this patch.