[lkml]   [1999]   [Jul]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Measured overhead of timer interrupts

    > why cannot it be fixed?

    Certainly, it can be fixed.

    My point is the following: /proc/net/* measures in HZ only things,
    which are meaningless for anyone but humans debugging kernel
    and reporting bugs. Applications need not them at all.

    When timers will be variable, /proc/net/ will reflect new status.
    Even now we have problems with mapping /proc/net to reality; f.e.
    /proc/net shows 32bit of timer and it was reason why I lost day more
    to catch the stupidest alpha bug, which would be evident
    if bug reporter saw higher bits.

    Besides that, we have several sysctl variables, measured in HZ, because
    sysctl interface in 2.2 did not allow to convert milliseconds to jiffies.
    It should be fixed, certainly.

    > we do not want to export HZ, why should we? HZ has no meaning to anything
    > else than the kernel. If the kernel exports HZ-dependent values into
    > /proc, then that has to be fixed. (yes it might be painful in some cases)
    > HZ might even go away in future kernels - what if we start using
    > nonperiodic timer interrupts?

    Mmm... HZ is necessary unixism measuring minimal timer resolution.
    If we will have timer with variable resolution, it will be revolution.
    What go you think, will this "future kernel" to schedule events
    in microsecond scale? It would be great improvement.

    BTW, seems, timer resolution is standartized by POSIX, hence we will have to
    emulate it in any case. 8)


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:53    [W:0.021 / U:12.760 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site