Re: Just a sanity check before I sumbit a buig report
On Fri, Mar 11, 2005 at 02:13:54PM -0600, Jon Noack wrote: Pete French wrote: Why does sysconf(_SC_CLK_TCK) always returns 128? Check out sysconf() in src/lib/libc/gen/sysconf.c (lines 83-84 of rev. 1.10): [follow through of code showing it is defined as a constant snipped] sysconf(3) states that _SC_CLK_TCK is the frequency of the statistics clock in ticks per second. Considering this value varies, returning a constant is wrong. Feel free to attach my email on the PR. An important use for sysconf(_SC_CLK_TCK) is to specify the rate of the results of times(3). (I don't know how many applications call that stupid function, getrusage() having been available for so long ;-) Currently, src/lib/libc/gen/times.c compiles this in just like sysconf.c does. So that's all ok; times.c will have to be modified too if sysconf(_SC_CLK_TCK) changes. getrusage(2) says that ru_ixrss is based on statistics clock ticks with a frequency of sysconf(_SC_CLK_TCK). This cannot be right. In other systems, getrusage often only really supports the timeval fields and perhaps the fault and swap counts; if it is supported, the ru_i?rss ticks are often not described at all or they are something strange like one per second. Consequently, this facility is nonportable and the tick frequency should be described using sysctl(). -- Jilles Tjoelker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Just a sanity check before I sumbit a buig report
getrusage(2) says that ru_ixrss is based on statistics clock ticks with a frequency of sysconf(_SC_CLK_TCK). This cannot be right. H... it was trying to interpret the results from getrusage which lead me to finding the bug. I notice that /usr/bin/time does a sysctl to get the clock rate in order to interpret the return values from getrusage. -pcf. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Just a sanity check before I sumbit a buig report
Why does sysconf(_SC_CLK_TCK) always returns 128? Check out sysconf() in src/lib/libc/gen/sysconf.c (lines 83-84 of rev. 1.10): [follow through of code showing it is defined as a constant snipped] To determine how stathz can vary, we'll have to dig deeper. Check out initclocks() in src/sys/kern/kern_clock.c (lines 196-213 of rev. 1.105.2.11): [follow through of code showing it depends on apm_attach() snipped] Thanks for that, most instructive! So the conclusion appears to be that sysconf(_SC_CLK_TCK) is doing the wrong thing by returning a constant then ? Thanks, I'll submit a pr about it. Do you mind if I attach your email to it to show the follow through of the code ? I havent looked at it myself in that much depth. -pcf. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Just a sanity check before I sumbit a buig report
Pete French wrote: Why does sysconf(_SC_CLK_TCK) always returns 128? Check out sysconf() in src/lib/libc/gen/sysconf.c (lines 83-84 of rev. 1.10): [follow through of code showing it is defined as a constant snipped] To determine how stathz can vary, we'll have to dig deeper. Check out initclocks() in src/sys/kern/kern_clock.c (lines 196-213 of rev. 1.105.2.11): [follow through of code showing it depends on apm_attach() snipped] Thanks for that, most instructive! So the conclusion appears to be that sysconf(_SC_CLK_TCK) is doing the wrong thing by returning a constant then ? Thanks, I'll submit a pr about it. Do you mind if I attach your email to it to show the follow through of the code ? I havent looked at it myself in that much depth. sysconf(3) states that _SC_CLK_TCK is the frequency of the statistics clock in ticks per second. Considering this value varies, returning a constant is wrong. Feel free to attach my email on the PR. Also, have you verified that apm is enabled and listed with flags 0x20 in the kernel config(s) of the problematic system(s)? Jon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Just a sanity check before I sumbit a buig report
'sysctl kern.clockrate' will return this information if you don't want to
write a program to do it for you :)
I was just using the code from time(1). Inteesring though - heres the
output:
kern.clockrate: { hz = 100, tick = 1, tickadj = 5, profhz = 100, stathz =
100 }
So that thinks stathz is 100, but sysconf(_SC_CLK_TCK) is returning 128!
What are the two machines? stathz is 128 on i386, 100 on sparc64, and 130
on amd64. Or thats the defaults at least.
These are all i386 machines - I have a number of them, all running 4.11.
I can take the same a.out and run it on all of them - on some both
numbers are 128, on other the numbers are 100 and 128.
If I go to one where both the calls return 128 though, the output
of 'sysctl kern.clockrate' is this:
kern.clockrate: { hz = 100, tick = 1, tickadj = 5, profhz = 1024, stathz =
128 }
So, it looks like theres a bug in sysconf(_SC_CLK_TCK) possibly ? because
it seems to be always returning 128, regardless of the value of stathz
as returned by 'sysctl kern.clockrate'
I can reproduce this on a number of machines BTW - the only things they have in
common is that I wrote their kernel config files at various points in time...
-pete.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Just a sanity check before I sumbit a buig report
Pete French wrote:
'sysctl kern.clockrate' will return this information if you don't want to
write a program to do it for you :)
I was just using the code from time(1). Inteesring though - heres the
output:
kern.clockrate: { hz = 100, tick = 1, tickadj = 5, profhz = 100, stathz =
100 }
So that thinks stathz is 100, but sysconf(_SC_CLK_TCK) is returning 128!
What are the two machines? stathz is 128 on i386, 100 on sparc64, and 130
on amd64. Or thats the defaults at least.
These are all i386 machines - I have a number of them, all running 4.11.
I can take the same a.out and run it on all of them - on some both
numbers are 128, on other the numbers are 100 and 128.
If I go to one where both the calls return 128 though, the output
of 'sysctl kern.clockrate' is this:
kern.clockrate: { hz = 100, tick = 1, tickadj = 5, profhz = 1024, stathz =
128 }
So, it looks like theres a bug in sysconf(_SC_CLK_TCK) possibly ? because
it seems to be always returning 128, regardless of the value of stathz
as returned by 'sysctl kern.clockrate'
I can reproduce this on a number of machines BTW - the only things they have in
common is that I wrote their kernel config files at various points in time...
I infer from your kern.clockrate output that you are running 4.x.
Why does sysconf(_SC_CLK_TCK) always returns 128? Check out sysconf()
in src/lib/libc/gen/sysconf.c (lines 83-84 of rev. 1.10):
**
case _SC_CLK_TCK:
return (CLK_TCK);
**
CLK_TCK is defined in src/include/time.h (line 52 of rev. 1.15):
**
#define CLK_TCK _BSD_CLK_TCK_
**
_BSD_CLK_TCK_ is defined in src/sys/i386/include/ansi.h (line 101 of
rev. 1.18.2.4):
**
#define_BSD_CLK_TCK_ 128
**
So on i386 (and FreeBSD 4.x), sysconf(_SC_CLK_TCK) will always return
128. If you look in src/sys/alpha/include/ansi.h, you'll see that on
alpha it will always return 100.
To determine how stathz can vary, we'll have to dig deeper. Check out
initclocks() in src/sys/kern/kern_clock.c (lines 196-213 of rev.
1.105.2.11):
**
/*
* Set divisors to 1 (normal case) and let the machine-specific
* code do its bit.
*/
psdiv = pscnt = 1;
cpu_initclocks();
#ifdef DEVICE_POLLING
init_device_poll();
#endif
/*
* Compute profhz/stathz, and fix profhz if needed.
*/
i = stathz ? stathz : hz;
if (profhz == 0)
profhz = i;
psratio = profhz / i;
**
stathz and profhz are originally set by cpu_initclocks() (which is MD).
If they are not set at this point, hz is used. This must be the case
for some of your machines as both stathz and profhz equal hz. So why
aren't stathz and profhz being set earlier? Check out cpu_initclocks()
in src/sys/i386/isa/clock.c (lines 995-1008 of rev. 1.149.2.6):
** if
(statclock_disable) {
/*
* The stat interrupt mask is different without the
* statistics clock. Also, don't set the interrupt
* flag which would normally cause the RTC to generate
* interrupts.
*/
stat_imask = HWI_MASK | SWI_MASK;
rtc_statusb = RTCSB_24HR;
} else {
/* Setting stathz to nonzero early helps avoid races. */
stathz = RTC_NOPROFRATE;
profhz = RTC_PROFRATE;
}
**
If you look in src/sys/isa/rtc.h, you'll see that RTC_NOPROFRATE=128 and
RTC_PROFRATE=1024. The only way stathz and profhz will not be set here
is if statclock_disable is true. Where is statclock_disable set? Check
out apm_attach() in src/sys/i386/apm/apm.c (lines 1032-1033 of rev.
1.114.2.6):
**
if (flags 0x20)
statclock_disable = 1;
**
Thus, you must have device apm0 flags 0x20 or something similar in
your kernel config file for you to get stathz and profhz as 100. apm is
disabled in GENERIC, so by default this is not a problem; apm_attach
won't be called if apm is disabled, so the fact that GENERIC includes
flags 0x20 is irrelevant.
Jon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Just a sanity check before I sumbit a buig report
On Tue, 8 Mar 2005, Pete French wrote: The man page for getrusage says that the frequency of the statistics clock is given by sysconf(_SC_CLK_TCK). The source code to /usr/bin/time uses a function 'getstathz' to get the frequency of the statistics clock which is does using sysctl and KERN_CLOCKRATE 'sysctl kern.clockrate' will return this information if you don't want to write a program to do it for you :) On my system the first returns 100Hz and the second 128Hz!!! What are the two machines? stathz is 128 on i386, 100 on sparc64, and 130 on amd64. Or thats the defaults at least. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Just a sanity check before I sumbit a buig report
The man page for getrusage says that the frequency of the statistics
clock is given by sysconf(_SC_CLK_TCK).
The source code to /usr/bin/time uses a function 'getstathz' to get
the frequency of the statistics clock which is does using sysctl
and KERN_CLOCKRATE
On my system the first returns 100Hz and the second 128Hz!!!
Now, is this:
1) A bug in /usr/bin/time
2) A bug in sysconf(_SC_CLK_TCK)
3) A bug in the manpage for getrusage
4) A bug in the kernel and the values should not be different
5) A bug in my understanding!
Note that although option '4' is unlikely, if I run the test a.out file
on other FreeBSD systems I get 128 for both values, which is even odder!
-pcf.
Test code (will probably give 128 for both on your system)
#include stdio.h
#include unistd.h
#include err.h
#include sys/types.h
#include sys/time.h
#include sys/sysctl.h
static int
getstathz()
{
struct clockinfo clockrate;
int mib[2];
size_t size;
mib[0] = CTL_KERN;
mib[1] = KERN_CLOCKRATE;
size = sizeof clockrate;
if (sysctl(mib, 2, clockrate, size, NULL, 0) == -1)
err(1, sysctl kern.clockrate);
return clockrate.stathz;
}
int
main()
{
printf(get stat hz = %d\n, getstathz());
printf(sysconf clock tick = %ld\n, sysconf(_SC_CLK_TCK));
return 0;
}
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
