lkml.org 
[lkml]   [2002]   [Jul]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: HZ, preferably as small as possible
    Date


    On Monday 15 July 2002 14:56, Linus Torvalds wrote:
    > On 15 Jul 2002, Robert Love wrote:
    > > A cleaner solution to this issue is a higher resolution timer, e.g. the
    > > high-res-timers project which has high resolution POSIX timers.
    >
    > But that really doesn't solve the problem either.
    >
    > You still need to have some limit on the timer resolution. Whether you
    > call that limit "HZ" or something else is irrelevant in the end. Just
    > calling them "high-resolution" doesn't make the problem go away, you still
    > have some resolution (*).
    >
    > So once you set some magic limit on the fine-grained resolution (let's
    > call that "MAX_FINE_HZ"), you might as well realize that that really is
    > 100% equivalent to just making HZ _be_ that value. Together with possibly
    > making the actual timer tick happen at a slower rate according to some
    > other heuristics (ie "the system doesn't need timers right now, let's just
    > not do them").
    >
    > Linus
    >
    > (*) Which is a lot less than the hw can generate, since you mustn't allow
    > users to bog down the system in timer interrupts by just using
    > "itimer(ITIMER_REAL, .. fine-resolution..)".

    actually, that is an interesting philosophical argument.

    in an embedded system, it is sometimes more useful to not put artificial
    constraints on the system and allow the clock and timer system to work in hw
    increments, but document the hell out of it.

    this is the "give 'em enough rope to hang themselves, but tell them the
    precise length of the rope" model.

    in an embedded system a "tickless" system is sometimes preferable to a ticked
    system. there is often only one or a very small number of processes/threads
    running and the extra overhead of 10 surplus clock ticks per process quantum
    is a waste of cycles. (also when using a ppc or similar modern chip(flame
    on;-), there is no need to keep a software wall clock, as the cpu has a 64bit
    free running counter)

    I had this discussion with george A. early in the posix timers project and I
    argued/begged for a compile time config option giving the option of ticked
    and tickless versions. George chose to go with a ticked system, because it
    benchmarked better in a general purpose system, particlularly under high
    loads, and he didn't have time to implement two systems. he made the right
    choice for the general purpose kernel and for probably 80% of the embedded
    market. (I'm in the other 20%)

    --
    /**************************************************
    ** Mark Salisbury || mbs@mc.com **
    **************************************************/
    -
    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/

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