Re: finding out the value of HZ from userspace

[Peter Williams <peterw@aurema.com>]

Bernd Petrovitsch wrote:
> On Die, 2004-03-16 at 06:53, Peter Williams wrote:
> 
>>Andi Kleen wrote:
>>
>>>Peter Williams <peterw@aurema.com> writes:
> 
> [...]
> 
>>>Already exists for a long time - AT_CLKTCK. glibc has a nice wrapper
>>>for it too (sysconf)
>>
>>So it does and POSIX.1 (_SC_CLK_TCK) compliant as well.  Unfortunately, 
>>the presence of this functionality makes it VERY difficult to understand 
>>why ticks are being converted from HZ==1000 values to HZ=100 values when 
>>they are being exported to user space especially as this conversion 
>>throws away precision.  Can anyone enlighten me?
> 
> 
> 1) Because Linux had long time HZ=100 hardcoded (except on Alphas) and
>    lots of applications probably use that value today (as HZ in their
>    source and not sysconf(...))  - especially since 2.4 (at least most
>    of them) has HZ=100 except for 64bit CPUs).

That is not a valid reason.  The programs should be fixed.

> 2) There are patches which dynamically change the CPU speed. And it
>    probably (IMHO) makes sense to change HZ dynamically too in that
>    situations. And a over-time changing HZ value is useless in
>    user-space.

I can't see why.  Ticks are used internally for process accounting (e.g. 
utime, stime, cutime and cstime) and if HZ was changing dynamically 
you'd have to visit every task and modify these values to be consistent 
with the changed value of HZ.  Even if HZ was allowed to change 
dynamically the values reported to user space should be in units 
appropriate to the MAXIMUM possible value of HZ so that precision is not 
lost.

Peter
-- 
Dr Peter Williams, Chief Scientist                peterw@aurema.com
Aurema Pty Limited                                Tel:+61 2 9698 2322
PO Box 305, Strawberry Hills NSW 2012, Australia  Fax:+61 2 9699 9174
79 Myrtle Street, Chippendale NSW 2008, Australia http://www.aurema.com