[PATCH] ia64: change usermode HZ to 250

[PATCH] ia64: change usermode HZ to 250

[hawkes]

include/asm-ia64/param.h defines HZ to be 1024 for usermode use, i.e.,
when the file gets installed as /usr/include/asm/param.h.
As the comment says:
    Technically, this is wrong, but some old apps still refer to it.  
    The proper way to get the HZ value is via sysconf(_SC_CLK_TCK).
At the very least, this technically wrong #define ought to reflect the
current default value (250) used by all arch/ia64 platforms.  No one uses
1024 anymore.  This makes those "old apps" (e.g., usr/bin/iostat) behave
properly for with a default kernel.  (And at some point, the define ought
to be removed altogether, which would expose all the applications that
erroneously expect HZ to be a compile-time constant.)

Signed-off-by: John Hawkes <hawkes@sgi.com>

Index: linux/include/asm-ia64/param.h
===================================================================
--- linux.orig/include/asm-ia64/param.h	2006-06-17 18:49:35.000000000 -0700
+++ linux/include/asm-ia64/param.h	2006-06-27 14:46:53.119407077 -0700
@@ -36,7 +36,7 @@
     * Technically, this is wrong, but some old apps still refer to it.  The proper way to
     * get the HZ value is via sysconf(_SC_CLK_TCK).
     */
-# define HZ 1024
+# define HZ 250
 #endif
 
 #endif /* _ASM_IA64_PARAM_H */

RE: [PATCH] ia64: change usermode HZ to 250

[Luck, Tony]

> -# define HZ 1024
> +# define HZ 250

Is every distribution just using the default 250? (How boring,
what't the use of CONFIG options if everyone makes the same choice).

No other architecture seems to want to be nice to applications,
I see "#define HZ 100" across most of them.  If this is going in,
it should fix all architectures.

Isn't the usual answer "applications should not include kernel
headers"?

-Tony

RE: [PATCH] ia64: change usermode HZ to 250

[Lee Revell]

On Tue, 2006-06-27 at 15:26 -0700, Luck, Tony wrote:
> > -# define HZ 1024
> > +# define HZ 250
> 
> Is every distribution just using the default 250? (How boring,
> what't the use of CONFIG options if everyone makes the same choice).
> 

No.  Multimedia oriented distros use 1000.

Lee

Re: [PATCH] ia64: change usermode HZ to 250

[Arjan van de Ven]

On Tue, 2006-06-27 at 15:01 -0700, hawkes@sgi.com wrote:
> include/asm-ia64/param.h defines HZ to be 1024 for usermode use, i.e.,
> when the file gets installed as /usr/include/asm/param.h.
> As the comment says:
>     Technically, this is wrong, but some old apps still refer to it.  
>     The proper way to get the HZ value is via sysconf(_SC_CLK_TCK).
> At the very least, this technically wrong #define ought to reflect the
> current default value (250) used by all arch/ia64 platforms.  No one uses
> 1024 anymore.  This makes those "old apps" (e.g., usr/bin/iostat) behave
> properly for with a default kernel.  (And at some point, the define ought
> to be removed altogether, which would expose all the applications that
> erroneously expect HZ to be a compile-time constant.)
> 
> Signed-off-by: John Hawkes <hawkes@sgi.com>
> 
> Index: linux/include/asm-ia64/param.h
> ===================================================================
> --- linux.orig/include/asm-ia64/param.h	2006-06-17 18:49:35.000000000 -0700
> +++ linux/include/asm-ia64/param.h	2006-06-27 14:46:53.119407077 -0700
> @@ -36,7 +36,7 @@
>      * Technically, this is wrong, but some old apps still refer to it.  The proper way to
>      * get the HZ value is via sysconf(_SC_CLK_TCK).
>      */
> -# define HZ 1024
> +# define HZ 250
>  #endif

ok why not define the userspace HZ to 

#define HZ sysconf(_SC_CLK_TCK)

?

RE: [PATCH] ia64: change usermode HZ to 250

[Arjan van de Ven]

On Tue, 2006-06-27 at 15:26 -0700, Luck, Tony wrote:
> > -# define HZ 1024
> > +# define HZ 250
> 
> Is every distribution just using the default 250? 

I would hope not; it's a pretty big regression for the telco space
(which really wants 1 or 2 msec delays) so I hope/assume all the
enterprise distributions (which ia64 specially cares about) stick to the
old 1024 value...

RE: [PATCH] ia64: change usermode HZ to 250

[Arjan van de Ven]

On Wed, 2006-06-28 at 11:47 +0100, Alan Cox wrote:
> Ar Mer, 2006-06-28 am 10:43 +0200, ysgrifennodd Arjan van de Ven:
> > I would hope not; it's a pretty big regression for the telco space
> > (which really wants 1 or 2 msec delays) so I hope/assume all the
> > enterprise distributions (which ia64 specially cares about) stick to the
> > old 1024 value...
> 
> 250 is also really bad for multimedia people. They would much rather
> have 300 than 250 as it divides nicely by 50 and by 60 for frame rates.

yup I know; I proposed that back when this was discussed but lost that
argument ;(

RE: [PATCH] ia64: change usermode HZ to 250

[Alan Cox]

Ar Mer, 2006-06-28 am 10:43 +0200, ysgrifennodd Arjan van de Ven:
> I would hope not; it's a pretty big regression for the telco space
> (which really wants 1 or 2 msec delays) so I hope/assume all the
> enterprise distributions (which ia64 specially cares about) stick to the
> old 1024 value...

250 is also really bad for multimedia people. They would much rather
have 300 than 250 as it divides nicely by 50 and by 60 for frame rates.

RE: [PATCH] ia64: change usermode HZ to 250

[Christoph Lameter]

On Wed, 28 Jun 2006, Arjan van de Ven wrote:

> On Wed, 2006-06-28 at 11:47 +0100, Alan Cox wrote:
> > Ar Mer, 2006-06-28 am 10:43 +0200, ysgrifennodd Arjan van de Ven:
> > > I would hope not; it's a pretty big regression for the telco space
> > > (which really wants 1 or 2 msec delays) so I hope/assume all the
> > > enterprise distributions (which ia64 specially cares about) stick to the
> > > old 1024 value...
> > 
> > 250 is also really bad for multimedia people. They would much rather
> > have 300 than 250 as it divides nicely by 50 and by 60 for frame rates.
> 
> yup I know; I proposed that back when this was discussed but lost that
> argument ;(

Maybe try again? I think we were not aware of that issue when the patch 
was submitted. And we had trouble following arguments in the flood of 
messages that followed.

You could also simply add a HZ choice of 300.

Re: [PATCH] ia64: change usermode HZ to 250

[John Hawkes]

From: "Arjan van de Ven" <arjan@infradead.org>
...
> ok why not define the userspace HZ to
>
> #define HZ sysconf(_SC_CLK_TCK)

That did occur to me.  It obviously does get the correct value.  The downside
is that one of those crufty apps that thinks it is using "HZ" as a constant
will instead be invoking a more costly syscall.  Should we care about the
resulting performance impact?

I vote for Arjan's solution.

John Hawkes

Re: [PATCH] ia64: change usermode HZ to 250

[John Daiker]

Alan Cox wrote:
> Ar Mer, 2006-06-28 am 08:43 -0700, ysgrifennodd John Hawkes:
>   
>>> #define HZ sysconf(_SC_CLK_TCK)
>>>       
>> That did occur to me.  It obviously does get the correct value.  The downside
>> is that one of those crufty apps that thinks it is using "HZ" as a constant
>> will instead be invoking a more costly syscall.  Should we care about the
>> resulting performance impact?
>>     
>
> Given that HZ can be cached by glibc the performance impact is minimal
> for most cases. The bigger problem will be code that does things with HZ
> that only work on compile time evaluation. At least for those you'll
> break at compile time.
>
> Either way its kind of irrelevant, the ABI set HZ. Its done, there are
> plenty of ways to change the kernel HZ without confusing userspace.
>
> Alan
>
>   
Alan, I agree with Arjan's solution as well.  From a very novice point 
of view, it makes sense to #define HZ as a syscall (which it technically 
should be anyway, right?).  Any performance hit isn't our problem... 
people should have been using the syscall to begin with... we're just 
forcing it on them this way!  :-)  That's my $0.02

John Daiker

Re: [PATCH] ia64: change usermode HZ to 250

[Alan Cox]

Ar Mer, 2006-06-28 am 08:43 -0700, ysgrifennodd John Hawkes:
> > #define HZ sysconf(_SC_CLK_TCK)
> 
> That did occur to me.  It obviously does get the correct value.  The downside
> is that one of those crufty apps that thinks it is using "HZ" as a constant
> will instead be invoking a more costly syscall.  Should we care about the
> resulting performance impact?

Given that HZ can be cached by glibc the performance impact is minimal
for most cases. The bigger problem will be code that does things with HZ
that only work on compile time evaluation. At least for those you'll
break at compile time.

Either way its kind of irrelevant, the ABI set HZ. Its done, there are
plenty of ways to change the kernel HZ without confusing userspace.

Alan

Re: [PATCH] ia64: change usermode HZ to 250

[Alan Cox]

Ar Mer, 2006-06-28 am 09:11 -0700, ysgrifennodd John Daiker: 
> people should have been using the syscall to begin with... we're just 
> forcing it on them this way!  :-)  That's my $0.02

In the cached HZ case there will be no performance hit of measure
anyway. The bigger problem is existing user space. That is why we've
always kept the user visible HZ based values the same when changing the
kernel HZ. You can't automatically regenerate all the old binaries you
might otherwise break.

Performance is only a minor issue, and I doubt anyone who cared about
performance would be using ia-64 anyway

[Grabs coat and exits..]

RE: [PATCH] ia64: change usermode HZ to 250

[Luck, Tony]

> In the cached HZ case there will be no performance hit of measure
> anyway. The bigger problem is existing user space. That is why we've
> always kept the user visible HZ based values the same when changing the
> kernel HZ. You can't automatically regenerate all the old binaries you
> might otherwise break.

No we haven't kept user visible HZ the same ... look at times(2)
it reports in "clock ticks", and has a note on the manual page
that you must use sysconf(_SC_CLK_TCK) to find out how many ticks
are in a second.  So dusty deck binaries with hard-coded 100 (or
even older ones with 60 or 50) have been broken for a while now.

Also note that the sysconf(_SC_CLK_TCK) call doesn't take a
system call, the kernel passes CLOCKS_PER_SEC in the AT_CLKTCK
auxilliary vector during fs/binfmt_elf.c:create_elf_tables(),
so glibc can complete this call with a simple table lookup in
userspace.

Fixing param.h to have #define HZ sysconf(_SC_CLK_TCK) sounds
like a plausible solution, many incorrect uses will be fixed
automagically by the next rebuild.  But some more obscure usages
of HZ may not compile (which is good, then they can be fixed
properly) or worse may compile, but not do the right thing.

Removing it completely might be better, it may force people to
look at how they are using HZ.  But there are probably many old
programs that have:

#ifndef HZ
#define HZ 60
#endif

So this won't catch them.

The ultimate safe solution might be:

#define HZ Fix your program to use sysconf(_SC_CLK_TCK)! \
	(and BTW, you should not include kernel headers)

Which is highly likely to cause a compile failure (but should
at least provide a clue to the user on what they should do).

-Tony

Re: [PATCH] ia64: change usermode HZ to 250

[Jes Sorensen]

>>>>> "Tony" == Luck, Tony <tony.luck@intel.com> writes:

Tony> Removing it completely might be better, it may force people to
Tony> look at how they are using HZ.  But there are probably many old
Tony> programs that have:

After reading through the discussion that was what I kept coming back
to.

Tony> #ifndef HZ #define HZ 60 #endif

Tony> So this won't catch them.

Tony> The ultimate safe solution might be:

Tony> #define HZ Fix your program to use sysconf(_SC_CLK_TCK)! \ (and
Tony> BTW, you should not include kernel headers)

Tony> Which is highly likely to cause a compile failure (but should at
Tony> least provide a clue to the user on what they should do).

You have my vote for that one. Anything else is just going to cause
those broken userapps to continue doing the wrong thing. We should
really do this on all archs though.

Cheers,
Jes

Re: [PATCH] ia64: change usermode HZ to 250

[Jes Sorensen]

Alan Cox wrote:
> Ar Iau, 2006-06-29 am 05:37 -0400, ysgrifennodd Jes Sorensen:
>> You have my vote for that one. Anything else is just going to cause
>> those broken userapps to continue doing the wrong thing. We should
>> really do this on all archs though.
> 
> No need, all current mainstream architectures expose a constant user HZ.

But you are still going to have the issue where someone installs their
own kernel and apps will break because of this? Getting the distros to
stop publishing a constant HZ is probably the right solution, but more
difficult :(

Cheers,
Jes

Re: [PATCH] ia64: change usermode HZ to 250

[Arjan van de Ven]

On Thu, 2006-06-29 at 12:48 +0200, Jes Sorensen wrote:
> Alan Cox wrote:
> > Ar Iau, 2006-06-29 am 05:37 -0400, ysgrifennodd Jes Sorensen:
> >> You have my vote for that one. Anything else is just going to cause
> >> those broken userapps to continue doing the wrong thing. We should
> >> really do this on all archs though.
> > 
> > No need, all current mainstream architectures expose a constant user HZ.
> 
Hi,

> But you are still going to have the issue where someone installs their
> own kernel and apps will break because of this?

to answer that question with one word: no.

read what Alan said: the HZ exposed to userspace is *constant*. For
example, the i386 user visible HZ is 100, even if the kernel runs at a
HZ of 250 or 1000.... Just when a HZ value gets exposed to userspace,
it's transformed into a HZ=100 based value.

And that's not a distribution thing, that's the kernel.org kernel
honoring the stable-userspace-interface contract, and common sense..

Greetings,
   Arjan van de Ven

Re: [PATCH] ia64: change usermode HZ to 250

[Alan Cox]

Ar Iau, 2006-06-29 am 05:37 -0400, ysgrifennodd Jes Sorensen:
> You have my vote for that one. Anything else is just going to cause
> those broken userapps to continue doing the wrong thing. We should
> really do this on all archs though.

No need, all current mainstream architectures expose a constant user HZ.

Alan

Re: [PATCH] ia64: change usermode HZ to 250

[Alan Cox]

Ar Iau, 2006-06-29 am 12:48 +0200, ysgrifennodd Jes Sorensen:
> > No need, all current mainstream architectures expose a constant user HZ.
> 
> But you are still going to have the issue where someone installs their
> own kernel and apps will break because of this? Getting the distros to
> stop publishing a constant HZ is probably the right solution, but more
> difficult :(

Read what I said - "all current mainstream architectures expose a
constant user HZ".

The HZ used by the kernel is independant of the HZ seen for /proc etc

Re: [PATCH] ia64: change usermode HZ to 250

[Jes Sorensen]

>>>>> "Arjan" == Arjan van de Ven <arjan@infradead.org> writes:

Arjan> read what Alan said: the HZ exposed to userspace is
Arjan> *constant*. For example, the i386 user visible HZ is 100, even
Arjan> if the kernel runs at a HZ of 250 or 1000.... Just when a HZ
Arjan> value gets exposed to userspace, it's transformed into a HZ=100
Arjan> based value.

Arjan> And that's not a distribution thing, that's the kernel.org
Arjan> kernel honoring the stable-userspace-interface contract, and
Arjan> common sense..

See what you mean, thanks.

Jes

Re: [PATCH] ia64: change usermode HZ to 250

[Albert Cahalan]

> Fixing param.h to have #define HZ sysconf(_SC_CLK_TCK) sounds
> like a plausible solution, many incorrect uses will be fixed
> automagically by the next rebuild.  But some more obscure usages
> of HZ may not compile (which is good, then they can be fixed
> properly) or worse may compile, but not do the right thing.

This makes compiles fail on one of the non-glibc libraries,
either uClibc or dietlibc, which does not provide sysconf.

The order in which procps tries things is:

1. walk off the end of environ to get the ELF notes
2. /proc/uptime to /proc/stat ratio
3. HZ
4. lame guess based on endianness and word size

I do not want sysconf. It is is an unreliable piece of shit
that gives me poor guesses instead of returning appropriate
error codes. It does this swell job while being damn slow.
I can do no worse with my own random guess.

(on my TODO list: count CPUs myself, because glibc often
thinks there are zero -- and this is not an error code)

> The ultimate safe solution might be:
>
> #define HZ Fix your program to use sysconf(_SC_CLK_TCK)! \
>       (and BTW, you should not include kernel headers)
>
> Which is highly likely to cause a compile failure (but should
> at least provide a clue to the user on what they should do).

This breaks perfectly fine code, except that it will be yet one more
thing for people to patch out when making headers for userspace.

Re: [PATCH] ia64: change usermode HZ to 250

[Jeremy Higdon]

On Thu, Jun 29, 2006 at 12:55:13PM +0200, Arjan van de Ven wrote:
> On Thu, 2006-06-29 at 12:48 +0200, Jes Sorensen wrote:
> > Alan Cox wrote:
> > > Ar Iau, 2006-06-29 am 05:37 -0400, ysgrifennodd Jes Sorensen:
> > >> You have my vote for that one. Anything else is just going to cause
> > >> those broken userapps to continue doing the wrong thing. We should
> > >> really do this on all archs though.
> > > 
> > > No need, all current mainstream architectures expose a constant user HZ.
> > 
> Hi,
> 
> > But you are still going to have the issue where someone installs their
> > own kernel and apps will break because of this?
> 
> to answer that question with one word: no.
> 
> read what Alan said: the HZ exposed to userspace is *constant*. For
> example, the i386 user visible HZ is 100, even if the kernel runs at a
> HZ of 250 or 1000.... Just when a HZ value gets exposed to userspace,
> it's transformed into a HZ=100 based value.
> 
> And that's not a distribution thing, that's the kernel.org kernel
> honoring the stable-userspace-interface contract, and common sense..


So does i386 convert the return value of the times(2) call to user
hertz?  On IA64, it returns the value in internal clock ticks, and
then when a program uses the value in param.h, it gets it wrong now,
because internal HZ is now 250.

So is times() is broken in IA64, or is this an exception to Alan's
statement?

jeremy

Re: [PATCH] ia64: change usermode HZ to 250

[Tony Luck]

> So does i386 convert the return value of the times(2) call to user
> hertz?  On IA64, it returns the value in internal clock ticks, and
> then when a program uses the value in param.h, it gets it wrong now,
> because internal HZ is now 250.
>
> So is times() is broken in IA64, or is this an exception to Alan's
> statement?

The Linux man page for times(2) specifically says "ticks" and refers
to sysconf for how to determine how long a "tick" is.  So ia64 matches
the man page.  Dunno if that matches POSIX though.

-Tony

Re: [PATCH] ia64: change usermode HZ to 250

[Arjan van de Ven]

> So does i386 convert the return value of the times(2) call to user
> hertz?  On IA64, it returns the value in internal clock ticks, and
> then when a program uses the value in param.h, it gets it wrong now,
> because internal HZ is now 250.
> 
> So is times() is broken in IA64, or is this an exception to Alan's
> statement?

yes it's broken; it needs to convert it to the original HZ (1024) and
make the sysconf() function also return 1024

Re: [PATCH] ia64: change usermode HZ to 250

[David Mosberger-Tang]

Nothing is broken.  Read Alan's statement carefully...

  --david

On 7/8/06, Arjan van de Ven <arjan@infradead.org> wrote:
>
>
> > So does i386 convert the return value of the times(2) call to user
> > hertz?  On IA64, it returns the value in internal clock ticks, and
> > then when a program uses the value in param.h, it gets it wrong now,
> > because internal HZ is now 250.
> >
> > So is times() is broken in IA64, or is this an exception to Alan's
> > statement?
>
> yes it's broken; it needs to convert it to the original HZ (1024) and
> make the sysconf() function also return 1024
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>


-- 
Mosberger Consulting LLC, http://www.mosberger-consulting.com/

RE: [PATCH] ia64: change usermode HZ to 250

[Luck, Tony]

> > So is times() is broken in IA64, or is this an exception to Alan's
> > statement?

> yes it's broken; it needs to convert it to the original HZ (1024) and


http://www.opengroup.org/onlinepubs/007908799/xsh/times.html

In which there is a typo: 

"Applications should use to determine the number of clock ticks
 per second as it may vary from system to system"

Clearly the word "sysconf" is missing between "use" and "to" (sysconf()
*is* listed in the SEE ALSO section).

I thought that part of the reason Linus raised HZ from 100 to 1000
on x86 was to help flush out pre-historic programs that didn't
know about sysconf() [With the hope that results that are off by
an order of magnitude would be absurd enough to get notice].

> make the sysconf() function also return 1024

Making sysconf lie about the actual system tick sounds such a
bad idea on so many levels!

-Tony

Re: [PATCH] ia64: change usermode HZ to 250

[Jeremy Higdon]

On Sat, Jul 08, 2006 at 07:07:14AM -0600, David Mosberger-Tang wrote:
> Nothing is broken.  Read Alan's statement carefully...
> 
>  --david

His statement can be read a couple of ways.

Let's go over the choices.

First, the background.  Some apps are using the HZ definition in
/usr/include/asm/param.h to get the system's HZ value.  That is a
bug in the app -- everyone agrees.

Currently, on IA64, HZ is defined to be 1024, which is incorrect
for newer kernels.

Options:

1. Change to 250, which will be correct for most distributions as
   well as the default IA64 kernel

2. Leave at 1024, which is wrong for everything

3. Change to sysconf(_SC_CLK_TCK) so that apps get the right thing

4. Change to something that produces a build error to indicate to app
   maintainer that he needs to fix something.

5. Change kernel to make it compatible with old apps that think
   system HZ is 1024.

Currently, the option chosen is (3).  It doesn't seem like the best
option to me -- maybe the worst, actually.  I would like to see at
least one explanation as to why it's been chosen.

jeremy

> On 7/8/06, Arjan van de Ven <arjan@infradead.org> wrote:
> >
> >
> >> So does i386 convert the return value of the times(2) call to user
> >> hertz?  On IA64, it returns the value in internal clock ticks, and
> >> then when a program uses the value in param.h, it gets it wrong now,
> >> because internal HZ is now 250.
> >>
> >> So is times() is broken in IA64, or is this an exception to Alan's
> >> statement?
> >
> >yes it's broken; it needs to convert it to the original HZ (1024) and
> >make the sysconf() function also return 1024

Re: [PATCH] ia64: change usermode HZ to 250

[David Mosberger-Tang]

On 7/10/06, Jeremy Higdon <jeremy@sgi.com> wrote:
> On Sat, Jul 08, 2006 at 07:07:14AM -0600, David Mosberger-Tang wrote:
> > Nothing is broken.  Read Alan's statement carefully...
> >
> >  --david
>
> His statement can be read a couple of ways.

Alan said:

--------------------------------------------------------------
From: Alan Cox <alan_at_lxorguk.ukuu.org.uk>
Date: 2006-06-29 21:02:08

Ar Iau, 2006-06-29 am 05:37 -0400, ysgrifennodd Jes Sorensen:
> You have my vote for that one. Anything else is just going to cause
> those broken userapps to continue doing the wrong thing. We should
> really do this on all archs though.

No need, all current mainstream architectures expose a constant user HZ.

Alan
--------------------------------------------------------------

Note that Alan didn't claim that *all* (Linux-supported) architectures
expose a constant user HZ, only the "mainstream" ones.  I won't get
into the debate as to what qualifies as "mainstream", but clearly IA64
does not (and should not) expose a constant value, since there were no
legacy-binary-issue and we chose to insist that apps should uses
sysconf() or equivalent if they need to know the clocktick.

  --david
-- 
Mosberger Consulting LLC, http://www.mosberger-consulting.com/

Re: [PATCH] ia64: change usermode HZ to 250

[Alan Cox]

Ar Llu, 2006-07-10 am 21:01 -0600, ysgrifennodd David Mosberger-Tang:
> Note that Alan didn't claim that *all* (Linux-supported) architectures
> expose a constant user HZ, only the "mainstream" ones.  I won't get

Indeed. IA64 likes to be different

> into the debate as to what qualifies as "mainstream", but clearly IA64
> does not (and should not) expose a constant value, since there were no
> legacy-binary-issue and we chose to insist that apps should uses
> sysconf() or equivalent if they need to know the clocktick.

In the case where you are running x86 binaries where you do need to
translate of course.

Alan

Re: [PATCH] ia64: change usermode HZ to 250

[Jeremy Higdon]

On Mon, Jul 10, 2006 at 09:01:53PM -0600, David Mosberger-Tang wrote:
> Note that Alan didn't claim that *all* (Linux-supported) architectures
> expose a constant user HZ, only the "mainstream" ones.  I won't get
> into the debate as to what qualifies as "mainstream", but clearly IA64
> does not (and should not) expose a constant value, since there were no
> legacy-binary-issue and we chose to insist that apps should uses
> sysconf() or equivalent if they need to know the clocktick.
> 
>  --david


Okay.  So what do you think about changing the value in param.h from
1024, so that it matches the new common value of 250, or is it best
just to leave it at 1024 and let applications that use it get the wrong
result?

jeremy

Re: [PATCH] ia64: change usermode HZ to 250

[David Mosberger-Tang]

On 7/11/06, Jeremy Higdon <jeremy@sgi.com> wrote:

> Okay.  So what do you think about changing the value in param.h from
> 1024, so that it matches the new common value of 250, or is it best
> just to leave it at 1024 and let applications that use it get the wrong
> result?

In my opinion, HZ needs to be a constant, since otherwise you could
break perfectly fine existing code (e.g., code which statically
initializes a variable with HZ and then picks up the correct frequency
from sysconf) and if you have to pick a particular constant, it seems
reasonable to me to pick the most commonly used frequency (which
appears to be 250Hz at the moment).

  --david
-- 
Mosberger Consulting LLC, http://www.mosberger-consulting.com/