cvs commit: src/sys/kern subr_param.c

Bruce Evans brde at optusnet.com.au
Sat May 10 11:21:51 UTC 2008


On Fri, 9 May 2008, Alfred Perlstein wrote:

> * Oliver Fromme <olli at fromme.com> [080509 02:08] wrote:
>>
>> Pawel Jakub Dawidek wrote:
>> >   Modified files:
>> >     sys/kern             subr_param.c
>> >   Log:
>> >   - Export HZ value via kern.hz sysctl (this is the same name as for the
>> >     loader tunable).
>>
>> It's probably just me, but I don't see the usefulness of
>> this.  The HZ value is already exported via kern.clockrate.
>> (I'm not saying the change is wrong, I'm just looking for
>> an explanation.)
>>
>> (On the other hand, how about exporting the value of the
>> kernel variable "ticks"?  Just a thought.)
>
> I've exported 'ticks' before for local hacks, it was useful, making it exported
> in FreeBSD would be a good idea.

Why all this bloat?

A ticks counter is already exported as a sysctl in kern.cp_time (add
up all the times to get a total.  Most statistics utilities do this).
Before FreeBSD-4, and still on systems with no separate statclock or
with stathz == hz like some of mine, this gives almost exactly the
same count as the kernel `ticks' variable.  It's hard to think of an
application where knowing the variable would be better than this in
cases where they are different.  Schedulers in the kernel don't use
the variable.  The variable might be more accurate due to HZ being
excessively large, but if you want accuracy, not to mention speed, use
clock_gettime(2).

I can never remember which sysctls give frequencies and often type
"sysctl -a | grep freq".  The one for hz is harder to find since it
spells "frequency" weirdly as "clockrate" in its name and as "hz" in
its output, so it doesn't show up in the above grep.

Bruce


More information about the cvs-all mailing list