24

I have seen this http://kaasxxx.wordpress.com/2008/01/22/linux-hz-checker/ But the script seems not to work. Does anyway know an easy way to check "HZ" in the terminal in Linux?

slm
  • 12,534
  • 12
  • 87
  • 106
Hao Shen
  • 2,257
  • 2
  • 32
  • 60
  • Perhaps this might help: http://www.advenage.com/topics/linux-timer-interrupt-frequency.php – Shawn Chin Sep 18 '12 at 15:54
  • scai did put an important comment on some answers regarding the mix-up of CONFIG_HZ and USER_HZ. According to this I updated my answer and added a note reg. history and meaning for terminal usage. – reichhart Sep 20 '19 at 17:46

6 Answers6

31

There's no uniform answer to this questions, as in some cases your kernel may be compiled "tickless" and not use a regular timer interrupt at all. But if you're on a traditional kernel and a traditional distro, you can find the current kernel's .config file under /boot with something like grep 'CONFIG_HZ=' /boot/config-$(uname -r).

Andy Ross
  • 10,859
  • 1
  • 28
  • 29
  • Works for Ubuntu 16.04. – Jingguo Yao Aug 18 '18 at 08:14
  • 1
    You are actually not checking the RUNNING kernel - just a config file which COULD be the one from the current running kernel. On some virtualized environments this won't work. – reichhart Dec 09 '18 at 15:40
  • Thus, "on a traditional kernel and a traditional distro". In general the kconfig for a kernel is not available at runtime. Thus "no uniform answer". – Andy Ross Dec 13 '18 at 18:40
17

The value of HZ can be determined like so:

$ getconf CLK_TCK
100

Any of the compile time options of the running kernel can be gleamed using getconf. Keep in mind that HZ is configurable:

$ man 7 time

The value of HZ varies across kernel versions and hardware platforms. On i386 the situation is as follows: on kernels up to and including 2.4.x, HZ was 100 giving a jiffy value of 0.01 seconds; starting with 2.6.0, HZ was raised to 1000, giving a jiffy of 0.001 seconds. Since kernel 2.6.13, the HZ value is a kernel configuration parameter and can be 100, 250 (the default) or 1000, yielding a jiffies value of, respectively, 0.01, 0.004, or 0.001 seconds. Since kernel 2.6.20, a further frequency is available: 300, a number that divides evenly for the common video frame rates (PAL, 25 HZ; NTSC, 30 HZ).

The times(2) system call is a special case. It reports times with a granularity defined by the kernel constant USER_HZ. User-space applications can determine thecvalue of this constant using sysconf(_SC_CLK_TCK).

As is typically the case you may need to trim the _SC_ bit off of the variable name shown in the man pages when inquiring about it using getconf.

slm
  • 12,534
  • 12
  • 87
  • 106
  • 4
    This gives me 100, but running `grep 'CONFIG_HZ=' /boot/config-$(uname -r)` yields 250. Any thoughts? – devoured elysium Jun 18 '19 at 12:40
  • 6
    `getconf CLK_TCK` aka `sysconf(_SC_CLK_TCK)` returns `USER_HZ` aka `CLOCKS_PER_SEC` which seems to be always 100 independent of the kernel configuration. This is *not* the same as `CONFIG_HZ` aka `HZ` which depends on the kernel configuration. That's why `getconf CLK_TCK` does *not* return the `CONFIG_HZ` value. – scai Sep 19 '19 at 09:33
  • This is the right answer. The OP should un-accept the accepted answer and accept this one instead. – Gunther Schadow Jan 20 '20 at 14:24
  • OK, actually the OP didn't say what kind of HZ he wants. I know of only one reason (at this time) to want some HZ, which is to interpret the numbers coming from /proc/stats. And for that you need the USER_HZ. – Gunther Schadow Jan 20 '20 at 14:26
6

There are many different approaches to get a hint on what your settings are. On some single-core systems this trick is handy:

/ # cat /proc/interrupts | grep -i time; sleep 10; cat /proc/interrupts | grep time
 16:   10404858      INTC  68 Level     gp_timer
 16:   10514798      INTC  68 Level     gp_timer

It shows you the amount of ticks there were during the 10 sec. sleep. Here about 100'000. Divide by 10 gives about 10'000 HZ.

This might get confusing on multicore systems, as it will be a per core list.

Another option will be to check if you can get a hand on the original kernel config. It would be stored in

/proc/config.gz

Unpack it and open the file. Search for parts that look similar to

CONFIG_HZ_FIXED=0
# CONFIG_HZ_100 is not set
# CONFIG_HZ_200 is not set
# CONFIG_HZ_250 is not set
# CONFIG_HZ_300 is not set
# CONFIG_HZ_500 is not set
# CONFIG_HZ_1000 is not set
CONFIG_HZ_10000=y
CONFIG_HZ=10000
CONFIG_SCHED_HRTICK=y

Just to warn you; 10'000 is way off normal settings. Experimental setup.

user3387542
  • 579
  • 1
  • 6
  • 26
5

UPDATE: Edited answer according to scai's comment.

In Bash the "HZ" calculation would look like e.g.

$ awk '{print$22/'$(tail -n 1 /proc/uptime|cut -d. -f1)"}" /proc/self/stat
100

Means: Take the 22nd value of uptime and divide it by the start time of the "self" process.

This delivers just the USER_HZ variable which is always 100 and not kernel's CONFIG_HZ variable.

Note: In ancient times there was only one HZ variable. I guess that "#define USER_HZ 100" was introduced with the split. And I guess also that in terminal/shell usage you are requiring USER_HZ and not CONFIG_HZ.

reichhart
  • 653
  • 6
  • 10
  • Field 22 is the start time of the process in clock ticks. [Scroll down to /proc/(pid)/stat](http://man7.org/linux/man-pages/man5/proc.5.html) – user1530335 Jun 22 '17 at 04:33
  • /proc/uptime has information of the system uptime. [The first number is the total number of seconds the system has been up.](https://www.centos.org/docs/5/html/5.1/Deployment_Guide/s2-proc-uptime.html) In essence reichhart is saying CONFIG_HZ will be `Clock Ticks since start (ticks) / Time since start (seconds)` units are `ticks / seconds` In most cases this should be 100 ticks per second. – user1530335 Jun 22 '17 at 04:41
  • 1
    I tried this and got a `HZ=100` result, but if I use `extract-ikconfig`, then I see `CONFIG_HZ=300`. Are these describing different things? – marshall.ward Nov 14 '18 at 04:19
  • No. It SHOULD be the same. According to https://github.com/torvalds/linux/blob/master/scripts/extract-ikconfig this tools will extract the setting from a kernel image. The only explanation I can give you is that you are checking a different kernel image than the one you are currently running. My "solution" is straight forward: You can check by yourself /proc/uptime and /proc/XXXX/stat (XXXX recently started) and divide manually by yourself. – reichhart Dec 09 '18 at 15:36
  • 1
    No, it should not be the same. These are two different clocks. Your proposed calculation returns `USER_HZ` aka `CLOCKS_PER_SEC` which seems to be always 100 independent of the kernel configuration. This is *not* the same as `CONFIG_HZ` aka `HZ` which depends on the kernel configuration. – scai Sep 19 '19 at 09:35
  • @scai: Big thanks for pointing to that! I updated the answer. – reichhart Sep 20 '19 at 17:04
0

What you're looking for is inside the configuration of the running kernel /proc/config.gz (if it is enabled, on most systems it is).

So you may check the resulting tick rate using:

zcat /proc/config.gz | grep CONFIG_HZ
thodnev
  • 1,411
  • 13
  • 18
  • 2
    Instead of zcat+grep you can also just use zgrep: `zgrep CONFIG_HZ /proc/config.gz` – scai Sep 23 '19 at 07:17
0

It seems like another way to achieve this same thing is by checking cat /proc/sys/kernel/sched_min_granularity_ns to get the nanosecond granularity of scheduling increment. For more details about how the scheduler works, check this page: https://www.kernel.org/doc/Documentation/scheduler/sched-design-CFS.txt

thesecretmaster
  • 1,887
  • 1
  • 24
  • 36