time to reconsider HZ?

time to reconsider HZ?

[David Mosberger]

Since most other Linux platforms which use HZ>100 use a HZ value of
1000, I'm thinking it may be safer to switch ia64 to HZ\x1000 as well
(principle of least difference possible is generally a good one...).

In the past, I was concerned that there might be enough code that
divides by HZ that this might not be such a hot idea, but I think this
may not (or at least no longer) be the case: I compiled the same
kernel once with HZ\x1000 and once with HZ\x1024 and the code-size
actually shrunk.

What do others think?

	--david

Re: time to reconsider HZ?

[Christoph Lameter]

On Fri, 14 Jan 2005, David Mosberger wrote:

> Since most other Linux platforms which use HZ>100 use a HZ value of
> 1000, I'm thinking it may be safer to switch ia64 to HZ\x1000 as well
> (principle of least difference possible is generally a good one...).
>
> In the past, I was concerned that there might be enough code that
> divides by HZ that this might not be such a hot idea, but I think this
> may not (or at least no longer) be the case: I compiled the same
> kernel once with HZ\x1000 and once with HZ\x1024 and the code-size
> actually shrunk.
>
> What do others think?

I think its not a big issue and may still be beneficial if occasions arise
where one has to divide by HZ. Do you know why the code size is reduced?

Re: time to reconsider HZ?

[David Mosberger]

>>>>> On Wed, 19 Jan 2005 08:54:09 -0800 (PST), Christoph Lameter <christoph@lameter.com> said:

  Christoph> I think its not a big issue and may still be beneficial
  Christoph> if occasions arise where one has to divide by HZ. Do you
  Christoph> know why the code size is reduced?

I assume it's because we're doing more tick -> msec than tick -> sec
conversions, but I haven't tried to verify that.  I agree that we
should first find out what the real reason for the code-size reduction
is before changing (though the "not wanting to be needlessly
different" argument still remains...).

	--david