SATA_SIL works with 2.6.7-bk8 seagate drive, but oops

With an older kernel I'd say he's losing 9% of his clock ticks. In this case though, incompatible /proc/stat changes are at fault. No longer does idle CPU time include IO-wait CPU time. This shouldn't have changed; user tools can subtract as needed.

I'm sorry to say that the HZ-guessing code is now only used for the 2.2.xx kernels. Over the years it has found many clock problems. Had the 2.4.xx kernels used a 64-bit jiffies counter, the HZ-guessing code would still be used.

You never did come up with an alternative to HZ-guessing that would work on those old 1200-HZ Alpha boxes, the ARM boxes that ran at 64 HZ and so on. I suppose you can blame the arch maintainers, but user-space has to deal with it. So HZ-guessing is a workaround for a kernel bug, especially because you claim that HZ (USER_HZ now) is part of the ABI.

well.... this value is *passed to userspace* via the AT_ attributes .... glibc probably nicely exports this info via sysconf(). I guess/hope your tools are now using that ?

Even then, it's a bug in my opinion. Yes, procps should be able to just use sysconf(_SC_CLK_TCK), but the fact is, using CLK_TCK and HZ is traditional unix behaviour, and we should just support it.

Linus

Agreed 100%. It gets kind of fun though if you have say 32 bit emulation in a 64 bit kernel and the 64 bit environment has a different user HZ than the 32 bit env....

It's not working right now, likely due to non-integer HZ. Here's a bug report.......

Even with the 2.6.7 kernel, I'm still getting reports of process start times wandering. Here is an example:

"About 12 hours since reboot to 2.6.7 there was already a difference of about 7 seconds between the real start time and the start time reported by ps. Now, 24 hours since reboot the difference is 10 seconds."

The calculation used is:

now - uptime + process_run_time

The code shown below works great on a 2.4.xx or earlier kernel. It generally relys on USER_HZ, which is supposedly in our ABI.

I have a feeling we'll forever be chasing bugs related to not using a PLL to drive the clock tick at exactly HZ ticks per second. Perhaps the DragonflyBSD code could be stolen. Anyway, the code:

/////////////////////////////////////////////////////////////////////////// unsigned long seconds_since_1970 = time(NULL);
unsigned long seconds_since_boot = uptime(0,0);
unsigned long time_of_boot = seconds_since_1970 - seconds_since_boot;
int pr_stime(char *restrict const outbuf, const proc_t *restrict const pp){
struct tm *proc_time;
struct tm *our_time;
time_t t;
const char *fmt;
int tm_year;
int tm_yday;
our_time = localtime(&seconds_since_1970); /* not reentrant */
tm_year = our_time->tm_year;
tm_yday = our_time->tm_yday;
t = time_of_boot + pp->start_time / Hertz;
proc_time = localtime(&t); /* not reentrant, this corrupts our_time */

  fmt = "%H:%M";                                   /* 03:02 23:59 */
  if(tm_yday != proc_time->tm_yday) fmt = "%b%d";  /* Jun06 Aug27 */
  if(tm_year != proc_time->tm_year) fmt = "%Y";    /* 1991 2001 */

return strftime(outbuf, 42, fmt, proc_time);
} ///////////////////////////////////////////////////////////////////////////

They use the AT_ attribute when it is provided. (Linux 2.4 and above only)

The glibc wrapper is defective; it takes a bad guess at HZ when the AT_ attribute is missing. Had sysconf() worked as documented, returning an error code on failure, it would have been used.

The sysconf() call for getting the number of CPUs is also broken, at least on SPARC. It would return a 0 instead of the proper -1 error code. I think it tried to scan /proc/cpuinfo for CPUs.

The fix for those should be that they should all export the same HZ to user space, regardless of any internal tick. So that's a kernel bug, in that those architectures expose the _internal_ HZ rather than some user-visible well-defined one.

If the user space tools didn't try to deal with it, the architectures would probably get fixed in a jiffy. All the support for kernel-to-user HZ conversion is there.

So I still maintain that procps should _not_ try to guess HZ. As it is, it's a bug, and it helps make excuses for _other_ bugs.

Linus