increasing HZ in Linux kernel

increasing HZ in Linux kernel

[Antonios G. Danalis]

Hello,

I want to increase the frequency of the clock interrupt up
to ~10000 to run some experiments.

In the kernel I'm using (2.4.2-2) I've noticed that
if you increase HZ above 1536 you get a conflict with
.../include/linux/timex.h:75-77
and if you add some lines there, you get a problem with
.../include/net/tcp.h:377
when HZ is above 4096.

Is there an easy way to increase clock interrupt freq, or
do I have to mess with the whole kernel ?

Thanks in advance.
Antonios

Re: increasing HZ in Linux kernel

[george anzinger]

"Antonios G. Danalis" wrote:
> 
> Hello,
> 
> I want to increase the frequency of the clock interrupt up
> to ~10000 to run some experiments.
> 
> In the kernel I'm using (2.4.2-2) I've noticed that
> if you increase HZ above 1536 you get a conflict with
> .../include/linux/timex.h:75-77
> and if you add some lines there, you get a problem with
> .../include/net/tcp.h:377
> when HZ is above 4096.
> 
> Is there an easy way to increase clock interrupt freq, or
> do I have to mess with the whole kernel ?
> 
The approach we are taking in the high-res-timers project
(http://sourceforge.net/projects/high-res-timers) is to leave HZ alone
and schedule timer interrupts as needed between the 1/HZ ticks.  I have
an kernel with most of the infrastructure ready to put on the
sourceforge site (today I hope), that you may want to look at.  Be
aware, however, it is not really a simple change.  You may also want to
look at the UTIME patch from the University of Kansas, which, to some
extent, is where I started.  We both leave HZ alone and schedule timer
ticks as needed to get high resolution.

As you have noted, changing HZ impacts other sub systems.  There is also
an issue of jiffie rollover which affects the longest time you can set
timers for.  Currently with HZ =100 and 32-bit integers, this is about
248.55 days.  If you move HZ to 1000, this moves to 24.855 days, and the
10,000 you want moves it to 2.4855 days which will give problems with at
least the cron sub system and probably a lot of others.

George

Re: increasing HZ in Linux kernel

[Frank Schneider]

george anzinger schrieb:
> 
> "Antonios G. Danalis" wrote:
> >
> > Hello,
> >
> > I want to increase the frequency of the clock interrupt up
> > to ~10000 to run some experiments.
> >
> > Is there an easy way to increase clock interrupt freq, or
> > do I have to mess with the whole kernel ?
> >
> The approach we are taking in the high-res-timers project
> (http://sourceforge.net/projects/high-res-timers) is to leave HZ alone
> and schedule timer interrupts as needed between the 1/HZ ticks.  I have
> an kernel with most of the infrastructure ready to put on the
> sourceforge site (today I hope), that you may want to look at.  Be
> aware, however, it is not really a simple change.  You may also want to
> look at the UTIME patch from the University of Kansas, which, to some
> extent, is where I started.  We both leave HZ alone and schedule timer
> ticks as needed to get high resolution.
> 
> As you have noted, changing HZ impacts other sub systems.  There is also
> an issue of jiffie rollover which affects the longest time you can set
> timers for.  Currently with HZ =100 and 32-bit integers, this is about
> 248.55 days.  

Sure ?
I think it is 497 days, jiffies is "unsigned long" on IA32.

(On PPC "HZ" is 1024, but i think there "jiffies" is 64-bit.)

I encountered this problem as my "/proc/uptime"-counter got over the
ridge and the machine now has an uptime of 550 days, but /proc/uptime
speaks of 550-497=53 days.

I also postet a patch against this effect, but this does only cosmetic
and no major changes to other things like "jiffies".

If you move HZ to 1000, this moves to 24.855 days, and the
> 10,000 you want moves it to 2.4855 days which will give problems with at
> least the cron sub system and probably a lot of others.

The rollover at my machine (2.2.10) did not do any harm, but that does
not mean that there will be no negative side-effect.

Solong..
Frank.

--
Frank Schneider, <SPATZ1@T-ONLINE.DE>.                           
Microsoft isn't the answer.
Microsoft is the question, and the answer is NO.
... -.-

Re: increasing HZ in Linux kernel

[george anzinger]

Frank Schneider wrote:
> 
> george anzinger schrieb:
> >
> > "Antonios G. Danalis" wrote:
> > >
> > > Hello,
> > >
> > > I want to increase the frequency of the clock interrupt up
> > > to ~10000 to run some experiments.
> > >
> > > Is there an easy way to increase clock interrupt freq, or
> > > do I have to mess with the whole kernel ?
> > >
> > The approach we are taking in the high-res-timers project
> > (http://sourceforge.net/projects/high-res-timers) is to leave HZ alone
> > and schedule timer interrupts as needed between the 1/HZ ticks.  I have
> > an kernel with most of the infrastructure ready to put on the
> > sourceforge site (today I hope), that you may want to look at.  Be
> > aware, however, it is not really a simple change.  You may also want to
> > look at the UTIME patch from the University of Kansas, which, to some
> > extent, is where I started.  We both leave HZ alone and schedule timer
> > ticks as needed to get high resolution.
> >
> > As you have noted, changing HZ impacts other sub systems.  There is also
> > an issue of jiffie rollover which affects the longest time you can set
> > timers for.  Currently with HZ =100 and 32-bit integers, this is about
> > 248.55 days.
> 
> Sure ?
> I think it is 497 days, jiffies is "unsigned long" on IA32.

That is when it rolls over.  What I am talking about is when the compare
of two unsigned numbers gives the wrong answer.  That happens when the
difference is greater than 1/2 of the max count.  This is independent of
the actual values so it really doesn't matter what the counts are, just
the differences to be compared.  The kernel code is very careful to do
the compare in such a way as to avoid the issues around the actual size,
but the max difference of 1/2 the value is another matter and can not be
avoided with out extra bits.

This is important as the add_timer code checks to see if the time has
passed yet.  If so it queues the timer for the next tick.  This will
happen when the timer is to expire more than 1/2 the max unsigned int
from now.

George
> 
> (On PPC "HZ" is 1024, but i think there "jiffies" is 64-bit.)
> 
> I encountered this problem as my "/proc/uptime"-counter got over the
> ridge and the machine now has an uptime of 550 days, but /proc/uptime
> speaks of 550-497=53 days.
> 
> I also postet a patch against this effect, but this does only cosmetic
> and no major changes to other things like "jiffies".
> 
> If you move HZ to 1000, this moves to 24.855 days, and the
> > 10,000 you want moves it to 2.4855 days which will give problems with at
> > least the cron sub system and probably a lot of others.
> 
> The rollover at my machine (2.2.10) did not do any harm, but that does
> not mean that there will be no negative side-effect.
> 
> Solong..
> Frank.
> 
> --
> Frank Schneider, <SPATZ1@T-ONLINE.DE>.
> Microsoft isn't the answer.
> Microsoft is the question, and the answer is NO.
> ... -.-