login
Search
Con Kolivas [interview] continues to maintain the performance oriented -ck patchset that he started in early 2004 [story], "this patchset is designed to improve system responsiveness and interactivity. It is configurable to any workload but the default -ck patch is aimed at the desktop and -cks is available with more emphasis on serverspace." In Con's latest release, 2.6.21-ck1, he notes that he has updated the patchset to include his improved SD cpu scheduler [story], "the staircase-deadline cpu scheduler has replaced the old staircase design in this version."
Con goes on to explain, "the staircase-deadline cpu scheduler can be set in either purely forward-looking mode for absolutely rigid fairness and cpu distribution according to nice level, or it can allow a small per-process history to smooth out cpu usage perturbations common in interactive tasks by enabling this sysctl. While small fairness issues can arise with this enabled, overall fairness is usually still strongly maintained and starvation is never possible. Enabling this can significantly smooth out 3d graphics and games." Swap prefetch [story] is also among the patches included in the -ck patchset.
From: Con Kolivas [email blocked] To: linux kernel mailing list [email blocked], ck list [email blocked] Subject: 2.6.21-ck1 Date: Fri, 4 May 2007 23:00:58 +1000 This patchset is designed to improve system responsiveness and interactivity. It is configurable to any workload but the default -ck patch is aimed at the desktop and -cks is available with more emphasis on serverspace. Apply to 2.6.21 http://www.kernel.org/pub/linux/kernel/people/ck/patches/2.6/2.6.21/2.6.21-ck1/patch-2.6.21-ck1.bz2 or server version http://www.kernel.org/pub/linux/kernel/people/ck/patches/2.6/2.6.21/2.6.21-ck1/patch-2.6.21-cks1.bz2 web: http://kernel.kolivas.org wiki: http://ck.wikia.com all patches: http://www.kernel.org/pub/linux/kernel/people/ck/patches/ Changes since 2.6.20-ck1: The staircase-deadline cpu scheduler has replaced the old staircase design in this version. The extra scheduling policies in 2.6.20-ck1 of SCHED_IDLEPRIO (idle cpu scheduling) and SCHED_ISO (unprivileged soft real time) have been rewritten and work in the same manner on this new scheduler. In almost all ways this should be a drop in replacement for the older -ck and no userspace changes should be required apart from deprecating the "compute" tunable (see below). More HZ options were added to this kernel. I have had repeated requests for this as people have found woefully coded binary only availability software that is dependant on the HZ value for performance (specifically the game servers). Since it's trivial to add extra values I offer (mostly unsupported) values up to 10000 HZ. People have found game servers benefitting from up to 4000 if I recall correctly. Note this patch will, unfortunately, cause a reject with 2.6.21.1 so if you wish to apply -ck to that kernel, please apply 2.6.21.1 first and then -ck and ignore the reject, or back out the hz-raise_max-2.patch The "interactive" tunable in /proc/sys/kernel/interactive still exists but its effects are now subtle, and fairness is still quite strongly maintained with it enabled, and starvation is still impossible. The -cks patch has this disabled by default. From the sysctl documentation included in Documentation/sysctl/kernel here is a summary: The staircase-deadline cpu scheduler can be set in either purely forward-looking mode for absolutely rigid fairness and cpu distribution according to nice level, or it can allow a small per-process history to smooth out cpu usage perturbations common in interactive tasks by enabling this sysctl. While small fairness issues can arise with this enabled, overall fairness is usually still strongly maintained and starvation is never possible. Enabling this can significantly smooth out 3d graphics and games. The "compute" tunable has been deprecated. The new tunable which is more flexible is the use of "rr_interval" /proc/sys/kernel/rr_interval and this describes the millisecond duration tasks at the same priority round robin between each other. The default value chosen is 6ms on UP on -ck and 10ms on UP on -cks. With more cpus it is scaled upwards. It can be changed on the fly up to 5000. Setting it to this has a similar and even more profound effect on throughput for pure cpu bound tasks but causes large increases in scheduling latency. This would be highly desirable for a render or compile farm machine though. Split patches available: http://www.kernel.org/pub/linux/kernel/people/ck/patches/2.6/2.6.21/2.6.21-ck1/patches/ Full patchlist: ck1-version.patch 2.6.21-sd-0.48.patch sched-sd-0.48-interactive_tunable.patch sched-range.patch sched-iso-5.4.patch track_mutexes-1.patch sched-idleprio-2.3.patch sched-limit_policy_changes.patch sched-add-above-background-load-function.patch cfq-ioprio_inherit_rt_class.patch cfq-iso_idleprio_ionice.patch mm-swap_prefetch-35.patch mm-convert_swappiness_to_mapped.patch mm-lots_watermark.diff mm-kswapd_inherit_prio-1.patch mm-prio_dependant_scan-2.patch mm-background_scan-2.patch mm-filesize_dependant_lru_cache_add.patch mm-idleprio_prio.patch kconfig-expose_vmsplit_option.patch hz-default_1000.patch hz-no_default_250.patch hz-raise_max-2.patch ck-desktop-tune.patch +/- 2.6.21-ck1-cks1.patch 乾杯 -- -ck
From: "David J. Wallace" [email blocked] Subject: Re: [ck] 2.6.21-ck1 Date: Fri, 4 May 2007 19:59:41 +0100 On Friday 04 May 2007 14:00, Con Kolivas wrote: > This patchset is designed to improve system responsiveness and > interactivity. It is configurable to any workload but the default -ck patch > is aimed at the desktop and -cks is available with more emphasis on > serverspace. Hi Con, I have 2.6.21-ck1 running happily on a variety of machines. Everything seems fine on both uniprocessor and SMP machines. I've been running SD for a couple of weeks now, including alternating between a SD patched kernel and an "old" staircase based kernel for a week of that. SD seems perfectly smooth. In fact on going back to the old kernel for a day I'm sure it felt more "choppy". I don't really do benchmarks, "feel" is more relevant to me. Right now I'd say my R4 "feels" better with SD than it has for a long time. Nice Job. Thanks for persisiting. As an aside I realized whilst trying non ck kernels the last few weeks just how much of a difference swap prefetch actually makes on a lowish memory machine such as this. Arigatou gozaimashita David
Great, love ck!
It's great to see the very nice -ck patchset get some well deserved exposure. I'm a trusty follower of the mailing list, and when I switch distro to a more DIY-friendly one (using Ubuntu Linux, will switch back to Arch Linux) I might switch kernels a bit more often - and test the experimental features.
Looking forward to it, -ck should really be included in the desktop oriented distros.
Scheduler
This is one of the remaining pieces of a non-microsoft solution.
MS has spent lots of time and research on the scheduler.
Its what makes DirectX and the desktop more palatable to Joe User and Joe Gamer.
Now that this MS Advantage has been erased....
Another thing I like about OSS: I can choose the scheduler as I see fit. You know the rest of the argument.
MS has spent lots of time
MS has spent lots of time and research on the scheduler.
Source?
I seriously doubt they've spent much money at all on the scheduler, because it sucks badly.
bad comments
you are breaking my heart junie...
My Grandma could have Googled this
(and shes dead)
Yes, it would be better to research the topic but...
embarrassing.....
my point is still valid.
Its nice to see a CHOICE in Linux.
Servers should RUN THE FRICKIN CODE, not SWITCH BETWEEN RUNNING CODE.
Workstations should spend all their CPU in mouse and screen pleasing users, not running code.
THE MS scheduler has been re-written multiple times over the NT kernel versions so as to get a more responsive front end. Its preemptive by design (NOT A SERVER). And it uses hints called quantums. Priorities too.
Meaning the OS's priority is to switch threads, not to let them run to completion (like Netware does).
How many "support" links do you want?
10?
20?
100?
Im Game.
Google Landy Wang, Dave Cutler, others.
Check out Channel9 for petes sake.
(Then get the truth elsewhere).
MS threw it all down in Ring Zero after the abomination called NT was created. Pretty soon Word will run in ring 0 "for performance reasons".
One might ask WHY NT put USER and GDI in userspace as a design decision in the first place (stability my a$$).....but ill leave that to the experts like you.
Im NOT complementing the MS scheduler (you can have any MS scheduler you want, as long as its the one you have now).
The reason Linux games are slow is because of X.
(Is there a Linux game that doesnt use X?)
X is just another program like top, not a system service.
Kinda like an interpreted language.
Im still surprised MS even came out with a game interface for a server, but, hey who cares when quake pushes up more frames eh?
(Of course MS calls any preempted system service DIRECT-something)
I.E., only MS can create an "API for direct-hardware access" and get away with calling it "DIRECT".
In that vein, i guess HAL.DLL is DIRECT-Microkernel.
The reason Linux games are
The reason Linux games are slow has nothing to do with X.
DRI direct rendering bypasses X entirely.
The reason Linux games are slow in the absence of other processes is because Linux GL drivers suck. The reason Linux GL drivers suck is because they are based on reverse engineered Windows drivers, because ATI and NVIDIA won't 1) allocate the resources to improve their proprietary drivers, and 2) provide any documentation at all to Linux developers, even under NDA.
No, what has made Windows
No, what has made Windows snappy is a fast GUI. It can render quickly and it routes input quickly. This is partly because the window manager and graphics server both live in kernelspace, so communicating with them is more like a system call than sending data through a socket or a shared-memory port and doing a full scale context switch like is the case with X. Secondly, the drivers are of good quality because they take full advantage of the hardware. In X, this is not the case due to lack of good hardware specs. And then there's Xlib and the toolkits, which are very inefficient with the X protocol.
The scheduler REALLY isn't at fault for responsiveness in Linux. It's all in the design and implementation of X.
I guess
Again,
CHOICE IS GOOD.
XCB
How's that going? It will surely fix the Xlib problems.
Parts is Parts
Schedulers
Memory Managers
Object Managers
Processes
Jobs
Handles
SMP
NUMA
Device Drivers
HALs
IDT
Traps
Signals
Exceptions
Interrupts
Kernel Threads
Performance Metrics
I/O
Context Switches
Idle Threads
Priority Boosting
Responsiveness (To who?)
Page Frames
Working Sets
Cache Coherency
Scheduler Design Decisions:
Do I
1) Make things happen
2) Wait for things to happen
3) Arrange things when they happen
When Do I hand off this quake rendering thread to CPU Core #8?
When CPU Core #1 goes 90%?
(Sorry Trick question - Carmack made it all single threaded)
http://www.gameinformer.com/News/Story/200701/N07.0109.1737.15034.htm
http://arstechnica.com/articles/paedia/hardware/crossplatform.ars/4
I think we are totally
I think we are totally over-emphasizing the need for a responsive CPU scheduler. If you are running CPU-intensive frontend tasks (like a 3D game), then you should disable all background processes. No need for a scheduler then.
If you have background tasks while you are working on your desktop, I never had any issues with them... unless they took a large share of I/O resources. So *that* is what we should address: to share I/O bandwidth in a good and sane way. Noone has even started to solve that issue and it is an issue a few magnitudes larger than the CPU scheduling issues...
Sorry guys, but from my perspective and experience your whole discussion is totally irrelevant.
Wrong
Not true. These things fall over -in the absence of any load- in linux thanks to scheduling anomalies. See http://lkml.org/lkml/2007/5/6/6 for how 3d and gaming can be badly handled just with X and a game alone.