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>] [day] [month] [year] [list]
Message-Id: <200704170913.24622.kernel@kolivas.org>
Date:	Tue, 17 Apr 2007 09:13:24 +1000
From:	Con Kolivas <kernel@...ivas.org>
To:	linux kernel mailing list <linux-kernel@...r.kernel.org>,
	ck list <ck@....kolivas.org>
Subject: Staircase cpu scheduler v17.1

Greetings all

Here is the current release of the Staircase cpu scheduler (the original 
generation I design that spurned development elsewhere for RSDL), for 
2.6.21-rc7

http://ck.kolivas.org/patches/pre-releases/2.6.21-rc7/2.6.21-rc7-ck1/patches/sched-staircase-17.1.patch

To remind people where this cpu scheduler fits into the picture:

-It is purpose built with interactivity first and foremost.
-It aims to be mostly fair most of the time
-It is has strong semantics desribing the cpu relationship between different 
nice levels (nice 19 is 1/20th the cpu of nice 0).
-It is resistant to most forms of starvation
-Latency of tasks that are not heavily cpu bound is exceptionally low 
irrespective of nice level -if they stay within their cpu bounds; What this 
means is you can have and audio application if it uses very little cpu 
running at nice 19 and it will still be unlikely to skip audio in the 
presence of a kernel compile nice -20.
-Therefore you can renice X or whatever to your heart's content, but then... 
you don't need to renice X with this design.
-The design is a single priority array very low overhead small codebase (the 
diffstat summary obviously muddied by removing more comments is 4 files 
changed, 418 insertions(+), 714 deletions(-))
4 files changed, 418 insertions(+), 714 deletions(-)

Disadavantages:
-There are heuristics
-There are some rare cpu usage patterns that can lead to excessive unfairness 
and relative starvation.

Bonuses:
With the addition of further patches in that same directory above it has:
- An interactive tunable flag which further increases the fairness and makes 
nice values more absolutely determine latency (instead of cpu usage vs 
entitlement determining latency as the default above)
/proc/sys/kernel/interactive 
- A compute tunable which makes timeslices much longer and has delayed 
preemption for maximum cpu cache utilisation for compute intensive workloads
/proc/sys/kernel/compute 
- A soft realtime unprivileged policy for normal users with a tunable maximum 
cpu usage set to 80% by default
/proc/sys/kernel/iso_cpu
- A background scheduling class that uses zero cpu usage resources if any 
other task wants cpu.

This is unashamedly a relatively unfair slightly starveable cpu scheduler with 
exceptional quality _Desktop_ performance as it was always intended to be. 

It is NOT intended for mainline use as mainline needs a general purpose cpu 
scheduler (remember!). I have no intention of pushing it as such given its 
disadvantages, and don't really care about those disadvantages as I have no 
intention of trying to "plug up" the theoretical exploits and disadvantages 
either since desktops aren't really affected BUT this scheduler is great fun 
to use. Unfortunately the version of this scheduler in plugsched is not up to 
date with this code. Perhaps if demand for plugsched somehow turns the world 
on its head then this code may have a place elsewhere too.

Enjoy! If you don't like it? Doesn't matter; you have a choice so just use 
something else. This is code that will only be in -ck.

-- 
-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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ