2002-02-24 21:35:58

by Tim Schmielau

[permalink] [raw]
Subject: HZ value used in kernel/acct.c

What is the supposed unit of the ac_etime field of struct acct?
The code in kernel/acct.c currently says

ac.ac_etime = encode_comp_t(jiffies - current->start_time);

so it is given in multiples of HZ, which makes this value
platform-dependent (and subject of overflow after 48.5 days with HZ=1024).
In include/linux/acct.h however there is the definition

#define AHZ 100

which somehow smells like the preferred time unit.
Comments?

Tim


2002-02-25 20:46:06

by Ragnar Hojland Espinosa

[permalink] [raw]
Subject: Re: HZ value used in kernel/acct.c

On Sun, Feb 24, 2002 at 10:35:33PM +0100, Tim Schmielau wrote:
> What is the supposed unit of the ac_etime field of struct acct?
> The code in kernel/acct.c currently says
>
> ac.ac_etime = encode_comp_t(jiffies - current->start_time);
>
> so it is given in multiples of HZ, which makes this value
> platform-dependent (and subject of overflow after 48.5 days with HZ=1024).
> In include/linux/acct.h however there is the definition
>
> #define AHZ 100
>
> which somehow smells like the preferred time unit.
> Comments?

The acct.c implementation followed FreeBSD's which also expressed comp_t
in terms platform dependant 1/(A)HZ You could check the "[Patch] fix
incorrect jiffies compares" thread for a fix on uptime and 64 bit jiffies
someone sent.. didn't pay attention in why it didn't get in, tho.

--
____/| Ragnar H?jland Freedom - Linux - OpenGL | Brainbench MVP
\ o.O| PGP94C4B2F0D27DE025BE2302C104B78C56 B72F0822 | for Unix Programming
=(_)= "Thou shalt not follow the NULL pointer for | (http://www.brainbench.com)
U chaos and madness await thee at its end." [20 pend. Mar 10]

2002-02-26 08:53:21

by Tim Schmielau

[permalink] [raw]
Subject: Re: HZ value used in kernel/acct.c

On Mon, 25 Feb 2002, Ragnar Hojland Espinosa wrote:
> On Sun, Feb 24, 2002 at 10:35:33PM +0100, Tim Schmielau wrote:
> > What is the supposed unit of the ac_etime field of struct acct?
[...]
>
> The acct.c implementation followed FreeBSD's which also expressed comp_t
> in terms platform dependant 1/(A)HZ You could check the "[Patch] fix
> incorrect jiffies compares" thread for a fix on uptime and 64 bit jiffies
> someone sent.. didn't pay attention in why it didn't get in, tho.
>
Actually it was me who started the thread :-)
The question arose when I went over the patch to do a final version for
submission to Marcelo and noticed that the 32bit values would overflow on
alpha after 48.5 days even with my patch.

However, there seems to be so little response that I will probably just
leave it the way it is now.

Tim