Re: finding out the value of HZ from userspace
From: Peter Williams
Date: Tue Mar 16 2004 - 18:49:10 EST
Bernd Petrovitsch wrote:
On Die, 2004-03-16 at 06:53, Peter Williams wrote:
Andi Kleen wrote:
Peter Williams <peterw@xxxxxxxxxx> 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@xxxxxxxxxx
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/