lkml.org 
[lkml]   [2001]   [Apr]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: #define HZ 1024 -- negative effects?
    Mike Galbraith wrote:
    >
    > On Fri, 27 Apr 2001, Nigel Gamble wrote:
    >
    > > On Fri, 27 Apr 2001, Mike Galbraith wrote:
    > > > On Fri, 27 Apr 2001, Nigel Gamble wrote:
    > > > > > What about SCHED_YIELD and allocating during vm stress times?
    > > >
    > > > snip
    > > >
    > > > > A well-written GUI should not be using SCHED_YIELD. If it is
    > > >
    > > > I was refering to the gui (or other tasks) allocating memory during
    > > > vm stress periods, and running into the yield in __alloc_pages()..
    > > > not a voluntary yield.
    > >
    > > Oh, I see. Well, if this were causing the problem, then running the GUI
    > > at a real-time priority would be a better solution than increasing the
    > > clock frequency, since SCHED_YIELD has no effect on real-time tasks
    > > unless there are other runnable real-time tasks at the same priority.
    > > The call to schedule() would just reschedule the real-time GUI task
    > > itself immediately.
    > >
    > > However, in times of vm stress it is more likely that GUI performance
    > > problems would be caused by parts of the GUI having been paged out,
    > > rather than by anything which could be helped by scheduling differences.
    >
    > Agreed. I wasn't thinking about swapping, only kswapd not quite keeping
    > up with laundering, and then user tasks having to pick up some of the
    > load. Anyway, I've been told that for most values of HZ the slice is
    > 50ms, so my reasoning wrt HZ/SCHED_YIELD was wrong. (begs the question
    > why do some archs use higher HZ values?)
    >
    Well, almost. Here is the scaling code:

    #if HZ < 200
    #define TICK_SCALE(x) ((x) >> 2)
    #elif HZ < 400
    #define TICK_SCALE(x) ((x) >> 1)
    #elif HZ < 800
    #define TICK_SCALE(x) (x)
    #elif HZ < 1600
    #define TICK_SCALE(x) ((x) << 1)
    #else
    #define TICK_SCALE(x) ((x) << 2)
    #endif

    #define NICE_TO_TICKS(nice) (TICK_SCALE(20-(nice))+1)

    This, by the way, is new with 2.4.x. As to why, it has more to do with
    timer resolution than anything else. Timer resolution is 1/HZ so higher
    HZ => better resolution. Of course, you must pay for it. Nothing is
    free :) Higher HZ means more interrupts => higher overhead.

    George
    -
    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 12:52    [W:0.024 / U:30.636 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site