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/
This archive was generated by hypermail 2b29 : Mon Apr 30 2001 - 21:00:22 EST