[lkml]   [2002]   [Jul]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: HZ, preferably as small as possible
    Martin Dalecki writes:
    > U\277ytkownik Jeff Garzik napisa\263:

    >> I don't see that making 'HZ' a variable is really an option, because
    >> many drivers and scheduler-related code will be wildly inaccurate as
    >> soon as HZ actually changes values.

    my_timeout = foo*HZ;

    >> So that leaves us with the option of changing all the code related to
    >> waiting to be based on msecs and usecs. Which I would love to do, but
    >> that's a lot of work, both code- and audit-wise.
    > vmstat.c:
    > hz = sysconf(_SC_CLK_TCK); /* get ticks/s from system */

    Oops! Sorry I missed that one. Not that it matters for
    the 2.5.25 kernel and above, but that code really should
    be using the Hertz value supplied by libproc.

    > And yes I know the libproc is *evil* in this area.

    Hell yes. It's going to remain evil until the 2.4 kernel
    is a distant memory. Debian uses a 2.2 kernel in the
    upcoming release, so it will be a good long time until
    everyone is using a 2.6 kernel. When 2.8 comes out,
    Debian will finally stop using 2.4 and I can get rid of
    my evil hack.

    Hey, I asked for a clean way to get HZ. I didn't even
    get "send a patch"; I got BS about the 2.5.25 behavior
    being standard, as if it had already been implemented.

    > The rest should be an implementation detail of sysconf().

    That's broken. It can't even correctly report the
    number of processors you have.
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:27    [W:0.025 / U:14.888 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site