linux-kernel - Re: RSDL v0.30 cpu scheduler for mainline kernels

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 16 Mar 2007 08:11:50 +1100
From:	Con Kolivas <kernel@...ivas.org>
To:	ray-gmail@...rabbit.org
Cc:	"Siddha, Suresh B" <suresh.b.siddha@...el.com>,
	"linux kernel mailing list" <linux-kernel@...r.kernel.org>,
	"ck list" <ck@....kolivas.org>
Subject: Re: RSDL v0.30 cpu scheduler for mainline kernels

On Friday 16 March 2007 05:58, Ray Lee wrote:
> On 3/15/07, Siddha, Suresh B <suresh.b.siddha@...el.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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/