On Sat, Aug 01, 2009 at 03:36:21PM -0400, Robert P. J. Day wrote:
> On Sat, 1 Aug 2009, Greg KH wrote:
>
> > On Fri, Jul 31, 2009 at 11:23:15AM +0700, Mulyadi Santosa wrote:
> > > On Fri, Jul 31, 2009 at 6:52 AM, Karel Zak<kzak@xxxxxxxxxx> wrote:
> > > It seems that user space sees HZ as 100, while in fact my current
> > > running kernel is compiled with HZ=300. What do you think about it? Or
> > > is there something wrong with my conclusion?
> >
> > The following C program should properly show you the kernel HZ.
> >
> > thanks,
> >
> > greg k-h
> >
> > --------------
> >
> > #include <unistd.h>
> > #include <time.h>
> > #include <stdio.h>
> >
> > int main()
> > {
> > struct timespec res;
> > double resolution;
> >
> > printf("UserHZ %ld\n", sysconf(_SC_CLK_TCK));
> >
> > clock_getres(CLOCK_REALTIME, &res);
> > resolution = res.tv_sec + (((double)res.tv_nsec)/1.0e9);
> >
> > printf("SystemHZ %ld\n", (unsigned long)(1/resolution + 0.5));
> > return 0;
> > }
>
> i already knew about sysconf. so i'm going to assume there's no
> simpler way to get the current HZ (either command line or /proc
> based).
But the point is, from userspace's point of view, the kernel HZ value
means NOTHING. See the above program that shows what the resolution
that userspace can use is. That is what userspace cares about, and what
the kernel provides. Internal HZ values of what the kernel might use
for scheduling means _nothing_.
So if you do provide it to userspace in a proc file, what then? What is
userspace going to do with such a value? It should never depend on it,
because it doesn't matter to it.
thanks,
greg k-h
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
