Re: RSDL v0.30 cpu scheduler for mainline kernels

[Con Kolivas <kernel@kolivas.org>]

On Friday 16 March 2007 05:58, Ray Lee wrote:
> On 3/15/07, Siddha, Suresh B <suresh.b.siddha@intel.com> wrote:
> > On Thu, Mar 15, 2007 at 05:05:13PM +1100, Con Kolivas wrote:
> > > On Thursday 15 March 2007 13:31, Siddha, Suresh B wrote:
> > > > Just to see the % increase in number of context switches, I ran 8
> > > > infinite loops (simple while(1); 's) and with 2.6.21-rc3 I see ~70
> > > > context switches every second, whereas with RSDL I see ~530 context
> > > > switches.
> > >
> > > Thanks. If it's just that then scaling rr interval with cpus somewhat
> > > would help. If you could, the following patch just to test might
> > > confirm that. -#define RR_INTERVAL          ((6 * HZ / 1001) + 1)
> > > +#define RR_INTERVAL          ((12 * HZ / 1001) + 1)
> >
> > Context switches now are ~370 per second. Still much above the regular
> > ~70 we see in the mainline.
> >
> > why do you say the rr_interval needs to be scaled with cpus? The basic
> > point in RSDL is, if we have more than one same priority task on a single
> > logic cpu, context switch happens every RR_INTERVAL (6 or 12 msec)
> > whereas in mainline it happens every 100 msec.

No. That's what we do with mainline too. The analogue of the RR_INTERVAL in 
mainline is the timeslice granularity. When I wrote it (TG) I assumed that 
any increase in latency by lengthening this value would be offset by more 
cpus being available which is only partially true. I also did not assume at 
the time that many cpus would be used on a desktop which is now, wrong. 

> With more CPUs, the context switch period can be multiplied by that
> number of CPUs while still allowing all tasks the same frequency of
> access to the CPU. With 4 processors, the context switch would be
> 24ms, by which point we're probably reaching the point of diminishing
> returns for minimizing overhead and maximizing throughput.
>
> > We need to minimize these context switches.
>
> That's a judgement call. If a synthetic benchmark degrades but other
> things improve, then this, as most everything in computer science, is
> yet another trade-off that needs to be evaluated. (You recognize there
> is a tradeoff here, right? Some benchmarks would improve even further
> if the switch time were 500ms. But that would make the system nearly
> unusable in general.)
>
> Ray

-- 
-ck