[lkml]   [2003]   [Jul]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch] sched-2.6.0-test1-G6, interactivity changes
On Mon, 28 Jul 2003, Ingo Molnar wrote:

> On Mon, 28 Jul 2003, Con Kolivas wrote:
> > On Sun, 27 Jul 2003 23:40, Ingo Molnar wrote:
> > > - further increase timeslice granularity
> >
> > For a while now I've been running a 1000Hz 2.4 O(1) kernel tree that
> > uses timeslice granularity set to MIN_TIMESLICE which has stark
> > smoothness improvements in X. I've avoided promoting this idea because
> > of the theoretical drop in throughput this might cause. I've not been
> > able to see any detriment in my basic testing of this small granularity,
> > so I was curious to see what you throught was a reasonable lower limit?
> it's a hard question. The 25 msecs in -G6 is probably too low.

It would seem to me that the lower limit for a given CPU is a function of
CPU speed and cache size. One reason for longer slices is to preserve the
cache, but the real time to get good use from the cache is not a constant,
and you just can't pick any one number which won't be too short on a slow
cpu or unproductively long on a fast CPU. Hyperthreading shrinks the
effective cache size as well, but certainly not by 2:1 or anything nice.

Perhaps this should be a tunable set by a bit of hardware discovery at
boot and diddled at your own risk. Sure one factor in why people can't
agree on HZ and all to get best results.

bill davidsen <>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

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: 2005-03-22 13:47    [W:0.070 / U:0.424 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site