Re: [xine-devel] kernel patching to improve xine performance

[Bill F. <bil...@mi...>]

Hi Miguel,

On 23 Apr 2003, Miguel Freitas wrote:

> On Wed, 2003-04-23 at 13:10, Bill Fink wrote:
> > I just checked my version of /usr/src/linux/include/asm/param.h
> > (on PPC), and it has:
> > 
> > #ifdef __KERNEL__
> > # define CLOCKS_PER_SEC HZ      /* frequency at which times() counts */
> > #endif
> > 
> > So at least on PPC it is advisable that CLOCKS_PER_SEC matches HZ
> > (this is on a 2.4.20-ben10 kernel).
> 
> afaik __KERNEL__ is not supposed to be defined when compiling user space
> programs. so while the HZ changes some constants internal to the kernel
> the "external" interface should still be the same.

Further checking reveals:

gwiz# grep -r CLOCKS_PER_SEC /usr/src/linux | grep -v 'define CLOCKS_PER_SEC'
/usr/src/linux/arch/ia64/ia32/binfmt_elf32.c:#undef CLOCKS_PER_SEC
/usr/src/linux/fs/binfmt_elf.c: NEW_AUX_ENT( 2, AT_CLKTCK, CLOCKS_PER_SEC);
/usr/src/linux/include/asm-ia64/ia32.h:#define IA32_CLOCKS_PER_SEC      100    /* Cast in stone for IA32 Linux */
/usr/src/linux/include/asm-ia64/ia32.h:#define IA32_TICK(tick)          ((unsigned long long)(tick) * IA32_CLOCKS_PER_SEC / CLOCKS_PER_SEC)

So one way CLOCKS_PER_SEC is used (the NEW_AUX_ENT line) is to pass
this information to user programs via the little known auxiliary data
that is located after the environment variables.  I believe there are
a few programs that utilize this data to find out the value of HZ on
the running system (as opposed to the value of HZ on the system that
the program was compiled on).  I actually have a sample program that
accesses this information.  I don't know offhand whether ntp uses this
capability or just uses the compile time HZ constant, and thus my
question of whether it is necessary or advisable to rebuild ntp from
source if you change the value of HZ.

						-Bill