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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 5 Mar 2007 01:04:09 +1100
From:	Con Kolivas <kernel@...ivas.org>
To:	ck@....kolivas.org
Cc:	linux kernel mailing list <linux-kernel@...r.kernel.org>
Subject: Re: [ANNOUNCE] RSDL completely fair starvation free interactive  cpu scheduler

On Sunday 04 March 2007 18:45, Con Kolivas wrote:
> On Sunday 04 March 2007 18:00, Con Kolivas wrote:
> > This message is to announce the first general public release of the
> > "Rotating Staircase DeadLine" cpu scheduler.
> >
> > Based on previous work from the staircase cpu scheduler I set out to
> > design, from scratch, a new scheduling policy design which satisfies
> > every requirement for SCHED_NORMAL (otherwise known as SCHED_OTHER) task
> > management.
> >
> > Available for download are:
> >
> >  A full rollup of the patch for 2.6.20:
> > http://ck.kolivas.org/patches/staircase-deadline/sched-rsdl-0.26.patch
>
> It's probably worth mentioning that this scheduler shows a not
> insignificant improvement in the mysql test case that recently received a
> lot of publicity. Why exactly that's the case I'm not sure but it may help
> track down what is actually responsible for the performance drop off as
> well. Note that the SMP balancing of this cpu scheduler is essentially
> unchanged from the mainline one.

Only preliminary other benchmarking has been done so far on RSDL, and so far 
the results are equal to or slightly better than mainline on scalability 
grounds.

These are the sysbench graphs just for completion that Nishanth Aravamudan 
performed. We were actually trying to track down the cause of the mysql 
performance problem and I suggested trying different cpu schedulers as well. 
Needless to say I'm not unhappy with the results although they haven't told 
us exactly where the problem lies but it certainly does add evidence that 
perhaps it is a scheduling issue.

-- 
-ck

Download attachment "transactions.png" of type "image/png" (7950 bytes)

Download attachment "idle.png" of type "image/png" (6317 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ