[lkml]   [2006]   [Jun]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRE: [PATCH] ia64: change usermode HZ to 250
    > In the cached HZ case there will be no performance hit of measure
    > anyway. The bigger problem is existing user space. That is why we've
    > always kept the user visible HZ based values the same when changing the
    > kernel HZ. You can't automatically regenerate all the old binaries you
    > might otherwise break.

    No we haven't kept user visible HZ the same ... look at times(2)
    it reports in "clock ticks", and has a note on the manual page
    that you must use sysconf(_SC_CLK_TCK) to find out how many ticks
    are in a second. So dusty deck binaries with hard-coded 100 (or
    even older ones with 60 or 50) have been broken for a while now.

    Also note that the sysconf(_SC_CLK_TCK) call doesn't take a
    system call, the kernel passes CLOCKS_PER_SEC in the AT_CLKTCK
    auxilliary vector during fs/binfmt_elf.c:create_elf_tables(),
    so glibc can complete this call with a simple table lookup in

    Fixing param.h to have #define HZ sysconf(_SC_CLK_TCK) sounds
    like a plausible solution, many incorrect uses will be fixed
    automagically by the next rebuild. But some more obscure usages
    of HZ may not compile (which is good, then they can be fixed
    properly) or worse may compile, but not do the right thing.

    Removing it completely might be better, it may force people to
    look at how they are using HZ. But there are probably many old
    programs that have:

    #ifndef HZ
    #define HZ 60

    So this won't catch them.

    The ultimate safe solution might be:

    #define HZ Fix your program to use sysconf(_SC_CLK_TCK)! \
    (and BTW, you should not include kernel headers)

    Which is highly likely to cause a compile failure (but should
    at least provide a clue to the user on what they should do).

    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: 2006-06-28 19:48    [W:0.023 / U:21.528 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site