How to modify the value of jiffies

[amit mehta_2]

Hi,

Is there a way to modify the jiffies ?
My main aim is to change the uptime value so
that i can reproduce one of our customer scenario.

~amit

[dirk dierickx]

i don't know of any way to do this, i don't think it was meant to be done.

you can change the HZ of a jiffie, but that only changes the interval when they get updated.

i guess the only chance you have of changing this value is when you enable kernel debugging.

[amit mehta_2]

Thx Dirk,

while browsing, i found this link and currently
trying to experiment with the same.

http://kerneltrap.org/node/464

~amit

[amit mehta_2]

hi Dirk,

I tried to change the variable HZ in linux-2.6..23.9/include/asm-i386/param.h
from 100 to 10000.
after which i rebuilt the kernel with following steps:
# make oldconfig
# make modules_install
# make install

Now when i boot from this newly built kernel, i wrote a small kernel module
to read the jiffies and HZ global variable,which is as follows:

[root@localhost drivers]# cat get_jiffies.c
#include
#include
#include
#include
#include
#include
static int __init jiffies_init(void)
{
unsigned long j,z;
j = z = 0;
j = jiffies;
z = HZ;
printk(KERN_ALERT "jiffies value is %lu\n",j);
printk(KERN_ALERT "jiffies value in seconds %lu\n",(jiffies/HZ));
printk(KERN_ALERT "HZ value is %lu\n",z);
return 0;
}

static void __exit jiffies_exit(void)
{
printk(KERN_ALERT "Goodbye, world!\n");
}

module_init(jiffies_init);
module_exit(jiffies_exit);

MODULE_LICENSE("GPL");

[root@localhost drivers]# insmod get_jiffies.ko
[root@localhost drivers]# dmesg
jiffies value is 372939
jiffies value in seconds 1491
HZ value is 250 <====

why this HZ variable is shown as 250 ?
i am a newbie in kernel programming and i might be doing something really stupid as well :(

~amit

[amit mehta_2]

hi Dirk,

After investigating further on this, i was
told that the value of HZ variable( include/asm-i386/param.h)might be getting overridden by value in kernel/Kconfig.hz

Hence i've modified the same file:

#
# Timer Interrupt Frequency Configuration
#

choice
prompt "Timer frequency"
default HZ_10000 <====
----
----
config HZ
int
default 100 if HZ_100
default 250 if HZ_250
default 300 if HZ_300
default 1000 if HZ_1000
default 10000 if HZ_10000



Also i've changed arch/i386/defconfig as:

arch/i386/defconfig:CONFIG_HZ_10000=y


Again i rebuilt the kernel and booted from it
and after inserting the same module,i get the same result :(


~amit

[Matti_Kurkela]

The "defconfig" file is the kernel source's "factory default" configuration for your system architecture. You did not specify how you're generating your kernel, but very probably it gets overridden by the kernel configuration of your distribution and/or your customized kernel configuration (in the .config file at the top of the kernel source tree).

You should be using e.g. "make menuconfig" or "make xconfig" to edit the configuration: there are certain dependency rules that must be enforced, or the configuration may not be valid. These configuration tools handle the dependencies automatically for you. Run "make help" at the top directory of the Linux kernel source to see all the possibilities.

The HZ value defines how many timer interrupts will happen per unit of time. Setting the HZ to a higher value will make any timer-interrupt-dependent things to be more responsive, at the cost of increased overhead (there will be more times when the timer interrupt has nothing meaningful to do).

The HZ value is also taken into account when calculating uptime, so simply changing the HZ will not make the uptime clock run any faster or slower than real time, unless there is a severe bug somewhere.

But back to your ultimate aim... you (or your customer) seems to be thinking there might be some problem that's related to uptime value. If it's in userspace, I think kernel modifications are not necessary for testing that: I think it should be possible to write a wrapper library (applicable to any dynamically-linked program using LD_PRELOAD) that modifies the uptime value perceived by that particular process. It might be easier to do than modifying the kernel.

Disclaimer: I'm a sysadmin, not a programmer. I have no idea of your skill level nor your customer scenario. But it seems to me that any time-dependent kernel-level problem would be more likely to be related to some data structure becoming full or fragmented over time, rather than the uptime value itself. So I'm curious: why is it thought that the uptime value might be significant?

MK

[amit mehta_2]

Thanks Matti.

Yes your assumption is right, the aim is to get the jiffies wraped up.
Basically jiffies are a kernel global variable
which counts number of ticks that have occured since the system booted.On a 32 bit machine, it can count upto 4294967295(i.e. 472 days), after which i guess this gets reset to 0.

HZ is tick rate which is different for different processors,
so if for a particular type of processor it is 250 then this means that processor will have 250 ticks in a second.
this value is configurable,which is defined in include/asm/param.h

Snip from my 2.6 linux kernel include/asm-i386/param.h file
#define HZ CONFIG_HZ

Now this CONFIG_HZ gets set to a value in arc//defconfig to a value after doing
make {menuconfig|xconfig}

Also uptime = jiffies * HZ
hence just by looking at these things, i could think of configuring the HZ to a large value in order to get the jiffies wrapped as early as possible(forget about the performance for some moment).

Here i come with loads of issues/failures :(
1: the 'make menuconfig' option gives you only 4 option
General setup->Processor type and feature -> Time fequency
here you can select one from {100|250|300|1000}.
All the changes/selections are written into .config file.
QUERRY:
I don't think it will work,but what if i go ahead and modify the CONFIG_HZ to something different than those mentioned above(i.e. 100|250|300|1000}in .config file ?

2: i've tried with setting HZ to both the minimum and max value(100 and 1000),but still
i didn't saw any changes in uptime.(i mean to say that the uptime was never too fast or too slow)

3: jiffies get reset at every reboot,but every time after reboot,when i insert my module to read jiffies,i get very large value for jiffies !!!(look at the code which i've pasted before),i think there is some problem with the code and it is not reading the correct,current value of jiffies.
because even if i keep the HZ value to 1000,it should take about 47 days for jiffies wrap up,but this is happening withing minutes on my machine !!

~amit

[Matti_Kurkela]

HZ used to be processor specific: for ix86 CPUs it was traditionally 100, for Alpha processors it was either 1000 or 1024, I think. But with 2.6 kernel series, it has become configurable so that you can pick one of the available options:

100 - the traditional value, suitable for servers running batch jobs: minimum overhead.

250 - a recently-added compromise value between 100 and 1000. Should allow good interactive response but not yet cause too bad overhead.

300 - the most recent addition: like 250, but with the added advantage that it is divisible by both 50 Hz and 60 Hz. They say this is important with some real-time video applications: think about TV picture refresh frequencies.

1000 - the value that allows the best interactive response, at the cost of maybe wasting some (smallish amount of) CPU power for timer interrupt processing.

If you (successfully) change the HZ value, the change will automatically be compensated in the uptime calculation too. The uptime will never be too fast nor too slow: changing the HZ will not affect it.

linux-/arch//defconfig is just a default configuration file: values from it are used if your current configuration file does not have a value for some required configuration option.

Look into your linux-/.config: it will have the various CONFIG_HZ_= options, but it will have a CONFIG_HZ= value too. The setting in .config will override anything specified in the defconfig file of your particular architecture.
So if you want to try a non-standard CONFIG_HZ value, you must set it in .config, not in the defconfig file.


The strange large number in the jiffies counter:

Back at the time when the HZ value on the ix86 architecture became configurable (with two options: either the traditional 100 or the Alpha-like 1000) someone noticed problems with the jiffies counter wrap-around. With the HZ value at 100, a long time would be needed to get the counter to wrap around, so the bug was not noticed before. But after increasing HZ to 1000, it became more obvious.

That bug was quickly fixed, but another feature was developed at the same time: the core kernel developers added an offset to the jiffies counter, so that it begins from a large value instead of zero. So the wrap-around happens earlier... making it possible to detect any counter wrap-around bugs much quicker.

See the file linux-/include/linux/jiffies.h:

/*
* Have the 32 bit jiffies value wrap 5 minutes after boot
* so jiffies wrap bugs show up earlier.
*/
#define INITIAL_JIFFIES ((unsigned long)(unsigned int) (-300*HZ))

So, in any recent kernels, the jiffies counter is initialized so that it *will* wrap around 5 minutes after boot, regardless of the HZ setting.

The jiffies.h file also sets some compile-time limits to the HZ value. At least in kernel 2.6.23.9, if the HZ value is not between 12 and 1536, the compilation will fail with an #error directive.

MK

[Srimalik]

If you increase Hz your uptime will wrap in a shorter time.

if Hz is set to 1000 , uptime will be reseted to 0 in ~49 days.

but now a 64 bit data structure(previously it was 32 bit) is used to hold this value and it ou can use a wrapper in userspace as suggested in previous posts to simulte your problem.

-Sri

[Matti_Kurkela]

Yes... the jiffies counter will wrap around, but the uptime will not. The uptime wrap-around bug was fixed quite a while ago... back in 2.4 kernel series, I think.

MK

[amit mehta_2]

Sorry for not updating anything from my side for a while,i got engaged in other things.

/*
* Have the 32 bit jiffies value wrap 5 minutes after boot
* so jiffies wrap bugs show up earlier.
*/
#define INITIAL_JIFFIES ((unsigned long)(unsigned int) (-300*HZ))



so this now resolves the issue of getting the higher jiffies value at the start in 2.6 kernel :)

Thanks Matti and Sri for throwing the light,Thank you very much.
Points to follow :)

~amit