[lkml]   [2002]   [Jul]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRE: Linux 2.4.19ac3rc3 on IBM x330/x340 SMP - "ps" time skew
Alan Cox wrote:
> > procps version is 2.0.7 (Debian 3.0).
> >
> > Where's the mistake -- should timer interrupts be on both
> > CPUs (I think this is the problem), or is procps miscalculating
> > Hz (seems less likely, someone would have noticed by now...)?
> HZ on x86 for user space is defined as 100. Its a procps problem

Slight error in my initial diagnosis of why procps is getting Hertz
wrong tho. It's not because timer interrupts are only happening
on one CPU. It's because it thinks I have 4 CPUs per system, when
really I only have 2 CPUs per system.

It's taking jiffies from the sum of the figures on the first line
of /proc/stat and dividing by the uptime in seconds from /proc/uptime
multiplied by the number of CPUs. The system has two CPUs, #0 and #1,
and is reporting _SC_NPROCESSORS_CONF as 4 (the count used by procps
as the number of CPUs).

Looks like even if it is procps's fault for not just using HZ==100,
the kernel is leading it astray by claiming I have twice as many
CPUs as I really do.

uyer@praxis8:~$ make cpus
cc cpus.c -o cpus
luyer@praxis8:~$ cat cpus.c
#include <unistd.h>

main () {
printf("%d\n", sysconf(_SC_NPROCESSORS_CONF));
luyer@praxis8:~$ ./cpus
luyer@praxis8:~$ grep 'processor ' /proc/cpuinfo
processor : 0
processor : 1
luyer@praxis8:~$ dmesg | grep -E 'Initializing CPU|CPU #. not
Initializing CPU#0
Initializing CPU#1
CPU #3 not responding - cannot use it.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:22    [W:0.115 / U:4.160 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site