How to know HZ from userspace?

How to know HZ from userspace?

[Harald Welte]

Hi!

Is there any way to read out the compile-time HZ value of the kernel?

I had a brief look at /proc/* and didn't find anything.

The background, why it is needed:

There are certain settings, for example the icmp rate limiting values,
which can be set using sysctl. Those setting are basically derived from
HZ values (1*HZ, for example).

If you now want to set those values from a userspace program / script in
a portable manner, you need to be able to find out of HZ of the currently
running kernel.

-- 
Live long and prosper
- Harald Welte / laforge@gnumonks.org               http://www.gnumonks.org/
============================================================================
GCS/E/IT d- s-: a-- C+++ UL++++$ P+++ L++++$ E--- W- N++ o? K- w--- O- M- 
V-- PS+ PE-- Y+ PGP++ t++ 5-- !X !R tv-- b+++ DI? !D G+ e* h+ r% y+(*)

Re: How to know HZ from userspace?

[H. Peter Anvin]

Followup to:  <20010530203725.H27719@corellia.laforge.distro.conectiva>
By author:    Harald Welte <laforge@gnumonks.org>
In newsgroup: linux.dev.kernel
> 
> Is there any way to read out the compile-time HZ value of the kernel?
> 
> I had a brief look at /proc/* and didn't find anything.
> 
> The background, why it is needed:
> 
> There are certain settings, for example the icmp rate limiting values,
> which can be set using sysctl. Those setting are basically derived from
> HZ values (1*HZ, for example).
> 
> If you now want to set those values from a userspace program / script in
> a portable manner, you need to be able to find out of HZ of the currently
> running kernel.
> 

Yes, but that's because the interfaces are broken.  The decision has
been that these values should be exported using the default HZ for the
architecture, and that it is the kernel's responsibility to scale them
when HZ != USER_HZ.  I don't know if any work has been done in this
area.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt

Re: How to know HZ from userspace?

[Joel Becker]

On Wed, May 30, 2001 at 05:07:22PM -0700, H. Peter Anvin wrote:
> Followup to:  <20010530203725.H27719@corellia.laforge.distro.conectiva>
> By author:    Harald Welte <laforge@gnumonks.org>
> In newsgroup: linux.dev.kernel
> > Is there any way to read out the compile-time HZ value of the kernel?
> 
> Yes, but that's because the interfaces are broken.  The decision has
> been that these values should be exported using the default HZ for the
> architecture, and that it is the kernel's responsibility to scale them
> when HZ != USER_HZ.  I don't know if any work has been done in this
> area.

	Pardon, but that still seems broken to me.  USER_HZ shouldn't
matter to the architecture either.  I would think that if
'echo 10 > /proc/foo/icmp_foo' sets a timeout of 10ms on alpha, it
should also do so on x86, sparc, and mips.  Why should the userspace
implementation *ever* have to know the 'architecture HZ', the 'real HZ'
or anything of the kind?

Joel

-- 

"I'm drifting and drifting
 Just like a ship out on the sea.
 Cause I ain't got nobody, baby,
 In this world to care for me."

			http://www.jlbec.org/
			jlbec@evilplan.org

Re: How to know HZ from userspace?

[Jonathan Lundell]

At 5:07 PM -0700 2001-05-30, H. Peter Anvin wrote:
>  > If you now want to set those values from a userspace program / script in
>>  a portable manner, you need to be able to find out of HZ of the currently
>>  running kernel.
>>
>
>Yes, but that's because the interfaces are broken.  The decision has
>been that these values should be exported using the default HZ for the
>architecture, and that it is the kernel's responsibility to scale them
>when HZ != USER_HZ.  I don't know if any work has been done in this
>area.

FWIW (perhaps not much in this context), the POSIX way is sysconf(_SC_CLK_TCK)

POSIX sysconf is pretty useful for this kind of thing (not just HZ, either).
-- 
/Jonathan Lundell.

Re: How to know HZ from userspace?

[Joel Becker]

On Wed, May 30, 2001 at 05:24:37PM -0700, Jonathan Lundell wrote:
> FWIW (perhaps not much in this context), the POSIX way is sysconf(_SC_CLK_TCK)
> 
> POSIX sysconf is pretty useful for this kind of thing (not just HZ, either).

	Well, how many hundred things on Linux are available from /proc
but not from sysconf or the like?  :-)

Joel

-- 

"There is no sincerer love than the love of food."  
         - George Bernard Shaw 

			http://www.jlbec.org/
			jlbec@evilplan.org

Re: How to know HZ from userspace?

[Jonathan Lundell]

At 1:38 AM +0100 2001-05-31, Joel Becker wrote:
>On Wed, May 30, 2001 at 05:24:37PM -0700, Jonathan Lundell wrote:
>>  FWIW (perhaps not much in this context), the POSIX way is 
>>sysconf(_SC_CLK_TCK)
>>
>>  POSIX sysconf is pretty useful for this kind of thing (not just HZ, either).
>
>	Well, how many hundred things on Linux are available from /proc
>but not from sysconf or the like?  :-)
>
>Joel

Lots. Maybe we oughta have /proc/sysconf/... (there's no reason 
sysconf() can't be a library reading /proc).
-- 
/Jonathan Lundell.

Re: How to know HZ from userspace?

[Mike Castle]

On Wed, May 30, 2001 at 05:44:39PM -0700, Jonathan Lundell wrote:
> Lots. Maybe we oughta have /proc/sysconf/... (there's no reason 
> sysconf() can't be a library reading /proc).

You don't mount proc?

mrc
-- 
     Mike Castle      dalgoda@ix.netcom.com      www.netcom.com/~dalgoda/
    We are all of us living in the shadow of Manhattan.  -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc

Re: How to know HZ from userspace?

[Daniel Phillips]

On Thursday 31 May 2001 02:44, Jonathan Lundell wrote:
> At 1:38 AM +0100 2001-05-31, Joel Becker wrote:
> >On Wed, May 30, 2001 at 05:24:37PM -0700, Jonathan Lundell wrote:
> >>  FWIW (perhaps not much in this context), the POSIX way is
> >>sysconf(_SC_CLK_TCK)
> >>
> >>  POSIX sysconf is pretty useful for this kind of thing (not just
> >> HZ, either).
> >
> >	Well, how many hundred things on Linux are available from /proc
> >but not from sysconf or the like?  :-)
>
> Lots. Maybe we oughta have /proc/sysconf/... (there's no reason
> sysconf() can't be a library reading /proc).

The other way round would make more sense.

--
Daniel

Re: How to know HZ from userspace?

[Martin Dalecki]

Joel Becker wrote:
> 
> On Wed, May 30, 2001 at 05:24:37PM -0700, Jonathan Lundell wrote:
> > FWIW (perhaps not much in this context), the POSIX way is sysconf(_SC_CLK_TCK)
> >
> > POSIX sysconf is pretty useful for this kind of thing (not just HZ, either).
> 
>         Well, how many hundred things on Linux are available from /proc
> but not from sysconf or the like?  :-)

Those hundert things which you either don't need or which should go to
syslog
or shouldn't be sysconf and nothing else.

Re: How to know HZ from userspace?

[Albert D. Cahalan]

Jonathan Lundell writes:
> At 5:07 PM -0700 2001-05-30, H. Peter Anvin wrote:

>>> If you now want to set those values from a userspace program / script in
>>>  a portable manner, you need to be able to find out of HZ of the currently
>>>  running kernel.
>>
>> Yes, but that's because the interfaces are broken.  The decision has
>> been that these values should be exported using the default HZ for the
>> architecture, and that it is the kernel's responsibility to scale them
>> when HZ != USER_HZ.  I don't know if any work has been done in this
>> area.

Nope.

HZ-derived values are not scaled in the /proc code.
The real value is not available to apps. (Linus said so)
People often change the HZ value.

Thus we have problems.

Maybe I'll post my disgusting hack. You _can_ get HZ out
of /proc if you know where to look. >:-)

> FWIW (perhaps not much in this context), the POSIX way is
> sysconf(_SC_CLK_TCK) POSIX sysconf is pretty useful for this
> kind of thing (not just HZ, either).

That does not report the real value. It reports the default.

Re: How to know HZ from userspace?

[Ralf Baechle]

On Wed, May 30, 2001 at 05:07:22PM -0700, H. Peter Anvin wrote:

> Yes, but that's because the interfaces are broken.  The decision has
> been that these values should be exported using the default HZ for the
> architecture, and that it is the kernel's responsibility to scale them
> when HZ != USER_HZ.  I don't know if any work has been done in this
> area.

We have such patches in the MIPS tree but I never dared to send them to
Linus ...

  Ralf

Re: How to know HZ from userspace?

[H. Peter Anvin]

Followup to:  <20010601035739.A1630@bacchus.dhis.org>
By author:    Ralf Baechle <ralf@uni-koblenz.de>
In newsgroup: linux.dev.kernel
>
> On Wed, May 30, 2001 at 05:07:22PM -0700, H. Peter Anvin wrote:
> 
> > Yes, but that's because the interfaces are broken.  The decision has
> > been that these values should be exported using the default HZ for the
> > architecture, and that it is the kernel's responsibility to scale them
> > when HZ != USER_HZ.  I don't know if any work has been done in this
> > area.
> 
> We have such patches in the MIPS tree but I never dared to send them to
> Linus ...
> 

Please do.

	-=hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt

Re: How to know HZ from userspace?

[Chris Wedgwood]

On Thu, May 31, 2001 at 09:12:00PM -0700, H. Peter Anvin wrote:

    Please do.

Well, I was quite keen on this (I often run with HZ==2048 and have to
have a hacked procps to accommodate) until someone pointed out we
could essentially abolosh HZ altogether, which seems like a much nice
solution to me.



  --cw

Re: How to know HZ from userspace?

[Albert D. Cahalan]

Harald Welte writes:

> Is there any way to read out the compile-time HZ value of the kernel?
> 
> I had a brief look at /proc/* and didn't find anything.

Look again, this time with a sick mind. Got your barf bag?
Kubys made me do it.

/****************************************************************/
/***********************************************************************\
*   Copyright (C) 1992-1998 by Michael K. Johnson, johnsonm@redhat.com *
*                                                                      *
*      This file is placed under the conditions of the GNU Library     *
*      General Public License, version 2, or any later version.        *
*      See file COPYING for information on distribution conditions.    *
\***********************************************************************/

/* ...but Albert Cahalan wrote the really evil parts.
MKJ is only guilty for the macro */

/* Sets Hertz equal to the kernel's HZ, as seen in /proc. */

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <ctype.h>

#include <unistd.h>
#include <fcntl.h>

#ifndef HZ
#include <netinet/in.h>  /* htons */
#endif

long smp_num_cpus;     /* number of CPUs */

#define BAD_OPEN_MESSAGE                                        \
"Error: /proc must be mounted\n"                                \
"  To mount /proc at boot you need an /etc/fstab line like:\n"  \
"      /proc   /proc   proc    defaults\n"                      \
"  In the meantime, mount /proc /proc -t proc\n"

#define STAT_FILE    "/proc/stat"
static int stat_fd = -1;
#define UPTIME_FILE  "/proc/uptime"
static int uptime_fd = -1;
#define LOADAVG_FILE "/proc/loadavg"
static int loadavg_fd = -1;
#define MEMINFO_FILE "/proc/meminfo"
static int meminfo_fd = -1;

static char buf[1024];

/* This macro opens filename only if necessary and seeks to 0 so
 * that successive calls to the functions are more efficient.
 * It also reads the current contents of the file into the global buf.
 */
#define FILE_TO_BUF(filename, fd) do{                           \
    static int local_n;                                         \
    if (fd == -1 && (fd = open(filename, O_RDONLY)) == -1) {    \
        fprintf(stderr, BAD_OPEN_MESSAGE);                      \
        fflush(NULL);                                           \
        _exit(102);                                             \
    }                                                           \
    lseek(fd, 0L, SEEK_SET);                                    \
    if ((local_n = read(fd, buf, sizeof buf - 1)) < 0) {        \
        perror(filename);                                       \
        fflush(NULL);                                           \
        _exit(103);                                             \
    }                                                           \
    buf[local_n] = '\0';                                        \
}while(0)

unsigned long Hertz;
static void init_Hertz_value(void) __attribute__((constructor));
static void init_Hertz_value(void){
  unsigned long user_j, nice_j, sys_j, other_j;  /* jiffies (clock ticks) */
  double up_1, up_2, seconds;
  unsigned long jiffies, h;
  smp_num_cpus = sysconf(_SC_NPROCESSORS_CONF);
  if(smp_num_cpus==-1) smp_num_cpus=1;
  do{
    FILE_TO_BUF(UPTIME_FILE,uptime_fd);  sscanf(buf, "%lf", &up_1);
    /* uptime(&up_1, NULL); */
    FILE_TO_BUF(STAT_FILE,stat_fd);
    sscanf(buf, "cpu %lu %lu %lu %lu", &user_j, &nice_j, &sys_j, &other_j);
    FILE_TO_BUF(UPTIME_FILE,uptime_fd);  sscanf(buf, "%lf", &up_2);
    /* uptime(&up_2, NULL); */
  } while((long)( (up_2-up_1)*1000.0/up_1 )); /* want under 0.1% error */
  jiffies = user_j + nice_j + sys_j + other_j;
  seconds = (up_1 + up_2) / 2;
  h = (unsigned long)( (double)jiffies/seconds/smp_num_cpus );
  /* actual values used by 2.4 kernels: 32 64 100 128 1000 1024 1200 */
  switch(h){
  case   30 ...   34 :  Hertz =   32; break; /* ia64 emulator */
  case   48 ...   52 :  Hertz =   50; break;
  case   58 ...   62 :  Hertz =   60; break;
  case   63 ...   65 :  Hertz =   64; break; /* StrongARM /Shark */
  case   95 ...  105 :  Hertz =  100; break; /* normal Linux */
  case  124 ...  132 :  Hertz =  128; break; /* MIPS, ARM */
  case  195 ...  204 :  Hertz =  200; break; /* normal << 1 */
  case  253 ...  260 :  Hertz =  256; break;
  case  393 ...  408 :  Hertz =  400; break; /* normal << 2 */
  case  790 ...  808 :  Hertz =  800; break; /* normal << 3 */
  case  990 ... 1010 :  Hertz = 1000; break; /* ARM */
  case 1015 ... 1035 :  Hertz = 1024; break; /* Alpha, ia64 */
  case 1180 ... 1220 :  Hertz = 1200; break; /* Alpha */
  default:
#ifdef HZ
    Hertz = (unsigned long)HZ;    /* <asm/param.h> */
#else
    /* If 32-bit or big-endian (not Alpha or ia64), assume HZ is 100. */
    Hertz = (sizeof(long)==sizeof(int) || htons(999)==999) ? 100UL : 1024UL;
#endif
    fprintf(stderr, "Unknown HZ value! (%ld) Assume %ld.\n", h, Hertz);
  }
}
/****************************************************************/

Re: How to know HZ from userspace?

[Harald Welte]

On Wed, May 30, 2001 at 11:40:30PM -0400, Albert D. Cahalan wrote:
> Harald Welte writes:
> 
> > Is there any way to read out the compile-time HZ value of the kernel?
> > 
> > I had a brief look at /proc/* and didn't find anything.
> 
> Look again, this time with a sick mind. Got your barf bag?
> Kubys made me do it.

;) 

First of all thanks for your recommended solution.

>   /* actual values used by 2.4 kernels: 32 64 100 128 1000 1024 1200 */
>   switch(h){
>   case   30 ...   34 :  Hertz =   32; break; /* ia64 emulator */
>   case   48 ...   52 :  Hertz =   50; break;
>   case   58 ...   62 :  Hertz =   60; break;
>   case   63 ...   65 :  Hertz =   64; break; /* StrongARM /Shark */
>   case   95 ...  105 :  Hertz =  100; break; /* normal Linux */
>   case  124 ...  132 :  Hertz =  128; break; /* MIPS, ARM */
>   case  195 ...  204 :  Hertz =  200; break; /* normal << 1 */
>   case  253 ...  260 :  Hertz =  256; break;
>   case  393 ...  408 :  Hertz =  400; break; /* normal << 2 */
>   case  790 ...  808 :  Hertz =  800; break; /* normal << 3 */
>   case  990 ... 1010 :  Hertz = 1000; break; /* ARM */
>   case 1015 ... 1035 :  Hertz = 1024; break; /* Alpha, ia64 */
>   case 1180 ... 1220 :  Hertz = 1200; break; /* Alpha */

As this is some kind of solution, it is not really generic enough. 
Nobody is prevented from setting his Hz value to 500 or any number coming
to his mind (i.e. when he wants to do something nasty with TBF of tc).

And if you actually look at x86-user-mode-linux, it is 20...


-- 
Live long and prosper
- Harald Welte / laforge@gnumonks.org               http://www.gnumonks.org/
============================================================================
GCS/E/IT d- s-: a-- C+++ UL++++$ P+++ L++++$ E--- W- N++ o? K- w--- O- M- 
V-- PS+ PE-- Y+ PGP++ t++ 5-- !X !R tv-- b+++ DI? !D G+ e* h+ r% y+(*)

Re: How to know HZ from userspace?

[H. Peter Anvin]

Followup to:  <20010531125225.O27719@corellia.laforge.distro.conectiva>
By author:    Harald Welte <laforge@gnumonks.org>
In newsgroup: linux.dev.kernel
> > 
> > Look again, this time with a sick mind. Got your barf bag?
> > Kubys made me do it.
> 
> ;) 
> 
> First of all thanks for your recommended solution.
> 

It's not *recommended*.  It's a bloody hack.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt

Re: How to know HZ from userspace?

[Erik Tews]

On Wed, May 30, 2001 at 08:37:25PM -0300, Harald Welte wrote:
> Hi!
> 
> Is there any way to read out the compile-time HZ value of the kernel?
> 
> I had a brief look at /proc/* and didn't find anything.
> 
> The background, why it is needed:
> 
> There are certain settings, for example the icmp rate limiting values,
> which can be set using sysctl. Those setting are basically derived from
> HZ values (1*HZ, for example).
> 
> If you now want to set those values from a userspace program / script in
> a portable manner, you need to be able to find out of HZ of the currently
> running kernel.

Have a look at the source of top. There is a lib which can help you to
find out HZ by reading some files from proc.

Re: How to know HZ from userspace?

[Tomas Telensky]

> Hi!
> 
> Is there any way to read out the compile-time HZ value of the kernel?

Why simply #include <asm/param.h>?

	Tomas


> 
> I had a brief look at /proc/* and didn't find anything.
> 
> The background, why it is needed:
> 
> There are certain settings, for example the icmp rate limiting values,
> which can be set using sysctl. Those setting are basically derived from
> HZ values (1*HZ, for example).
> 
> If you now want to set those values from a userspace program / script in
> a portable manner, you need to be able to find out of HZ of the currently
> running kernel.
> 
> -- 
> Live long and prosper
> - Harald Welte / laforge@gnumonks.org               http://www.gnumonks.org/
> ============================================================================
> GCS/E/IT d- s-: a-- C+++ UL++++$ P+++ L++++$ E--- W- N++ o? K- w--- O- M- 
> V-- PS+ PE-- Y+ PGP++ t++ 5-- !X !R tv-- b+++ DI? !D G+ e* h+ r% y+(*)
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: How to know HZ from userspace?

[Harald Welte]

On Wed, Jun 06, 2001 at 08:09:33PM +0200, Tomas Telensky wrote:
> > Hi!
> > 
> > Is there any way to read out the compile-time HZ value of the kernel?
> 
> Why simply #include <asm/param.h>?

because the include file doesn't say anything about the HZ value of 
the currently running kernel, but only about some kernel source somewhere
on your harddrive?


> 	Tomas

-- 
Live long and prosper
- Harald Welte / laforge@gnumonks.org               http://www.gnumonks.org/
============================================================================
GCS/E/IT d- s-: a-- C+++ UL++++$ P+++ L++++$ E--- W- N++ o? K- w--- O- M- 
V-- PS+ PE-- Y+ PGP++ t++ 5-- !X !R tv-- b+++ DI? !D G+ e* h+ r% y+(*)

Re: How to know HZ from userspace?

[Tomas Telensky]

> On Wed, Jun 06, 2001 at 08:09:33PM +0200, Tomas Telensky wrote:
> > > Hi!
> > > 
> > > Is there any way to read out the compile-time HZ value of the kernel?
> > 
> > Why simply #include <asm/param.h>?
> 
> because the include file doesn't say anything about the HZ value of 
> the currently running kernel, but only about some kernel source somewhere
> on your harddrive?

This _SHOULD_ correspond on each linux instalation. But if you would
distribute a binary to other people it's a problem.

(note that I'm running an rc script, which sets the symlink /usr/src/linux
properly at boottime ... this should be everywhere)

There is also one way how to guess HZ - calibrate :-)))
Recently I've done more difficult thing - I not only guess the HZ value, I
also guess the time when the tick comes. But it uses a bit of statistics and 
may be inaccurate on loaded systems. And you need TSC :-)

	Tomas

Re: How to know HZ from userspace?

[Harald Welte]

On Wed, Jun 06, 2001 at 08:59:51PM +0200, Tomas Telensky wrote:
> > On Wed, Jun 06, 2001 at 08:09:33PM +0200, Tomas Telensky wrote:
> > > > Hi!
> > > > 
> > > > Is there any way to read out the compile-time HZ value of the kernel?
> > > 
> > > Why simply #include <asm/param.h>?
> > 
> > because the include file doesn't say anything about the HZ value of 
> > the currently running kernel, but only about some kernel source somewhere
> > on your harddrive?
> 
> This _SHOULD_ correspond on each linux instalation. But if you would
> distribute a binary to other people it's a problem.

I my initial mail I wrote that I'm talking about user-mode-linux. So for
example you compile a program, copy it into your user-mode-linux filesystem,
and it won't work anymore. (recompiling is also not an option, who has a 
kernel source installed inside his user-mode-linux root filesystem).

and what happens if you recompile your kernel with a different HZ (because
of tc's TBF or something)... then you would have to recompile your userspace
application afterwards?

nah. That's not a solution.

I'd say:

- Either change all sysctl variables to be HZ-independent, or
- Create a sane way to read HZ from the running kernel.

Everything else is broken, from my point of view.

> 	Tomas

-- 
Live long and prosper
- Harald Welte / laforge@gnumonks.org               http://www.gnumonks.org/
============================================================================
GCS/E/IT d- s-: a-- C+++ UL++++$ P+++ L++++$ E--- W- N++ o? K- w--- O- M- 
V-- PS+ PE-- Y+ PGP++ t++ 5-- !X !R tv-- b+++ DI? !D G+ e* h+ r% y+(*)

Re: How to know HZ from userspace?

[Linus Torvalds]

In article <20010530203725.H27719@corellia.laforge.distro.conectiva>,
Harald Welte  <laforge@gnumonks.org> wrote:
>
>Is there any way to read out the compile-time HZ value of the kernel?

In 2.4.x, you'll get it on the stack as one of the ELF auxilliary
entries (AT_CLKTCK). 

Strictly speaking that's the "frequency at which 'times()' counts", ie
the kernel CLOCKS_PER_SEC, not HZ. But from a user perspective the two
should hopefully always be the same (if any of the /proc fields etc
should really use CLOCKS_PER_SEC, not HZ).

		Linus

Re: How to know HZ from userspace?

[Chris Wedgwood]

On Wed, Jun 06, 2001 at 01:55:53PM -0700, Linus Torvalds wrote:

    In 2.4.x, you'll get it on the stack as one of the ELF auxilliary
    entries (AT_CLKTCK). 
    
    Strictly speaking that's the "frequency at which 'times()' counts", ie
    the kernel CLOCKS_PER_SEC, not HZ. But from a user perspective the two
    should hopefully always be the same (if any of the /proc fields etc
    should really use CLOCKS_PER_SEC, not HZ).

I would hope nobody actually uses the above.  Since I run kernels
with HZ==2048 and started having to hack various userland tools to
make them happy I too was after this information.

However, it was pointed out that eliminated HZ completely might be a
better idea, and then just exporting all values to userspace as
nanoseconds or similiar... a radically different approach to what we
have now but something that struck me as a really good idea.

Fodder for 2.5.x perhaps?



  --cw

Re: How to know HZ from userspace?

[H. Peter Anvin]

On Fri, 1 Jun 2001, Peter Waltenberg wrote:

> Yes, I know we have a chance of being rescheduled simply because "something
> else" has also yielded. However thats fairly hit and miss.
>
> I don't disagree with your statement that thats how the interface should be
> designed, but the most of the apps that could use it still have an unreliable
> interface. i.e. you ask to be woken in 2.54mS, on X86 it'll likely be ~10mS,
> on Alpha ~3mS. Now and then you'll get woken somewhere near the time you
> requested.
>

First of all, the unit of time is the second (s), not the siemens (S).

Second, I think we're talking about different things.  I'm talking about
interfaces (/proc, ioctl, etc.) in which durations are specified in
jiffies.  This is unacceptable.

What you seem to be talking about is user-space insight into the
scheduling algorithm, which is another matter.

	-hpa