Description of problem: gkrellm consistently mis-report numbers of running procs Version-Release number of selected component (if applicable): gkrellm-2.2.10-3.fc7 How reproducible: Always. Steps to Reproduce: 1. Start gkrellm; 2. Enable Built-ins=>Procs; 3. Observe number of running processes reported; 4. Compare with results of top, ksysguard, or any other such tool. Actual results: Number of running processes reported is consistently and significantly higher than all other such tools; top/ksysguard/etc. usually agree exactly. Expected results: Accurate report of number of running processes IAW top/ksysguard/etc. Additional info: uname -a: Linux presario.localdomain 2.6.23.15-80.fc7 #1 SMP Sun Feb 10 17:29:10 EST 2008 i686 athlon i386 GNU/Linux Linux micron-pc-rb.localdomain 2.6.23.15-80.fc7 #1 SMP Sun Feb 10 17:29:10 EST 2008 i686 i686 i386 GNU/Linux Linux etower.localdomain 2.6.23.15-80.fc7 #1 SMP Sun Feb 10 17:29:10 EST 2008 i686 i686 i386 GNU/Linux Smolt: http://smolt.fedoraproject.org/show?UUID=pub_b4a1d9f5-e2fd-4428-86a4-e1839f36e6da http://smolt.fedoraproject.org/show?UUID=pub_4caba599-039f-4ac7-ae9a-d03c56e839b3 http://smolt.fedoraproject.org/show?UUID=pub_136d9c2b-6c5c-4414-9069-040715716a4c
I see what you mean, but thats not gkrellm's fault it gets this number from /proc/loadavg, and that seems to be at fault. So I'm reassigning this to the kernel. kernel-maintainers: according to all docs I can find, including: http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/ref-guide/s1-proc-topfiles.html The number after the / in /proc/loadavg should be the total number of processes on the system, but this seems to be way of, almost twice as much as the actual number processes (according to top / ps aux) Vince is your machine a dual core or maybe a hyperthreaded P4?
No. There are three machines (specs+smolt links above), all three with the same basic Fedora 7 software, all three with the same symptoms/results: (1) Compaq Presario SR2020NX (desktop PC), CPU=AMD 64 3500+ (~2.2 GHz, stepped @1.0/1.8/2.0/2.2 using cpuspeed on-demand service), Linux presario.localdomain 2.6.23.15-80.fc7 #1 SMP Sun Feb 10 17:29:10 EST 2008 i686 athlon i386 GNU/Linux, http://smolt.fedoraproject.org/show?UUID=pub_b4a1d9f5-e2fd-4428-86a4-e1839f36e6da; (2) Micron.pc ClientPro CN, CPU=Pentium III (Coppermine, ~800MHz), Linux micron-pc-rb.localdomain 2.6.23.15-80.fc7 #1 SMP Sun Feb 10 17:29:10 EST 2008 i686 i686 i386 GNU/Linux, http://smolt.fedoraproject.org/show?UUID=pub_4caba599-039f-4ac7-ae9a-d03c56e839b3; (3) EMachines etower 466id, CPU=Celeron (Mendocino, ~466MHz), Linux etower.localdomain 2.6.23.15-80.fc7 #1 SMP Sun Feb 10 17:29:10 EST 2008 i686 i686 i386 GNU/Linux, http://smolt.fedoraproject.org/show?UUID=pub_136d9c2b-6c5c-4414-9069-040715716a4c. Also, I should note that this condition has persisted for quite a long time (6+months? 1year?), however, I considered it to be a fairly low personal priority ans so just now got around to reporting it. Thanx and Regards, VJSchiavoni
/proc/loadavg includes threads in the count. If you do 'ps Haxh | wc -l' you will see the count does match what is in there.