# 2.6.7-ck5 released (latest snapshot: 2.6.8-rc1-ck5)

## kerframil

EDIT: latest official edition is 2.6.7-ck5, latest snapshot is 2.6.8-rc1-ck5 (see this post)

Hello folks. Well, as per the subject Mr Kolivas has recently released his -ck4 patchset. This one is interesting because it brings the staircase scheduler policy (effectively, the raison d'etre of the patchset) to version 7.8 and indeed, it certainly seems to be becoming rather mature.

Also worthy of note is the addition of ability to configure CONFIG_HZ (that's the frequency of the timer which controls the task scheduler). This used to default to 100Hz in 2.4 (providing a maximum granularity of 10ms for a single scheduling "slice") and was rasied to 1000Hz in 2.6 (providing a granularity of 1ms). Users of slower systems might find it beneficial to reduce the frequency (see Con's page for details). Those who are interested in throughput - servers, heavily stressed workstations, computational clusters - might prefer 100Hz. However, if you take the route of altering the default then be sure to evaluate the effect on performance carefully. The scheduler may well be generally tuned to behave better at 1000Hz.

The changes from -ck3 to -ck4 only involved some fixes to staircase as follows:

Yield logic made robust. Tasks that yield go after everything else, but once scheduled are seen as their normal priority - lots of applications use yield and this makes them behave a lot better.

Uninterruptible sleep has no effect on burst during interactive mode - this improves the responsiveness under I/O load

The 'non-interactive' and 'compute' mode is now much stricter about cpu distribution

Code cleanupsI haven't checked whether an ebuild is in circulation yet, but the usual "create an overlay, copy, rename" trick should work fine (personally, I patch my sources manually).

NOTE TO WINEX/CEDEGA USERS: Some of the programming in these products is a little sloppy which can lead to regressions in performance. For instance, I found that sound would stutter when using a kernel with the staircase scheduler. These issues can be resolved by starting the program with a higher nice level like so:

```
$ nice -n 19 cedega C:\Games\MyLovelyGame.exe
```

Furthermore, Con has recently created a ck mailing list, so be sure to check it out if you are interested in his work.

With recent 2.6 kernels, I believe pre-empt to be generally detrimental to performance for most desktop purposes so I recommend that it remains disabled. I would be interested to hear of any observations regarding that point or the use of -ck in general.Last edited by kerframil on Thu Jul 15, 2004 12:26 am; edited 4 times in total

----------

## AlterEgo

2.6.7-ck is buzzing nicely here. I am not using prempt, but I am using the new 1.0.6106 nvidia drivers and 4k stacks.

Staircase scheduler feels more balanced than in ck1, where I experienced some mouse stutter under heavy load (i.e. opening a VM in Vmware whilst compiling firefox  :Cool:  )

Happy   :Very Happy: 

----------

## teutzz

how about reiser4 support? is there any? I couldn't find any info about that in Con's page   :Confused: 

----------

## swimmer

Well, now comes the stupid question: how do I activate the staircase scheduler? I can't see anything passing the bootlog which gives me an hint that it is used ...

Sorry for the stupid question   :Confused: 

swimmer

----------

## gringo

 *Quote:*   

> how do I activate the staircase scheduler?

 

Staircase is activated as the default cpu scheduler, CFQ I/O scheduler is activated as default too.

And i must say im impressed about the latest ck performance on my system. 

Thanks to Kerframil to pointing me to write-back-lat, didnt know about this; i also added some other stuff from -mm & lkml instead of preemptive and im very happy with the result.

Time to see how new love feels   :Wink: 

----------

## manny15

I used to have 2.6.3-ck1/ck2 And things worked well. Now with 2.6.7-ck2, XMMS stutters while doing even the simplest tasks (like when FireFox draws a page, when I scroll up and down in FireFox, when compiling the kernel) I used to do all these things the xmms NEVER stressed. I've tried setting elevator=cfg and not setting it. Setting /proc/sys/kernel/interactive to 0 helps a bit, but this is crazy. Right now I'm compiling the kernel again with a few changes to see if it helps. I'm disabling premption, and setting the timer (CONFIG_HZ) to 500. Has anyone experienced this?

----------

## Skrot

 *manny15 wrote:*   

> I've tried setting elevator=cfg and not setting it.

 It's elevator=cfq, and in ck-sources is enabled by default. You can change it to anticipatory with elevator=as.

----------

## barry

I had some problems with stuttering sound with earlier 2.6.7 ck releases, even moving windows would do it - I find the problem has gone away now with the later ones.

----------

## manny15

Sorry for the typo. It's true that cfq is enabled by default, I saw something about it during boot. I'm switched it to as and with a CONFIG_HZ of 500. I know I shouldn't make more that one change at a time, but oh well. So far, I've only heard stutter here and there. But I'm actually stressing it out (prelink and equery at the same time). Thanks!

----------

## Tuti

i love this kernel

the only thing i changed was reversing the bootsplash314 patch and applying  bootsplash314-sp2 which is framebuffer independent and runs fine on radeonfb (no more need for the annoying vesa refresh rate stuff)

----------

## ed0n

 *teutzz wrote:*   

> how about reiser4 support? is there any? I couldn't find any info about that in Con's page  

 

I manually patched that. -ck4 is working just fine in my machine.

----------

## fallow

I`m staircase fan too  :Smile:  , i feel new stair is much better , and a few of old problems are gone ....  :Smile:  also rc_paraller_startup is working . I think also spa_staircase hibryd is a good solution and spa - hydra scheduler.

 *ed0n wrote:*   

>  *teutzz wrote:*   how about reiser4 support? is there any? I couldn't find any info about that in Con's page   
> 
> I manually patched that. -ck4 is working just fine in my machine.

 

so it is without mm,which reiser4 snapshot did You use ? Is many rejects in this ?, i didn`t try to apply reiser4 snpashot for no-mm sources but , i`m looking to do it beacause i personaly have mixed feelings and experiences with mm:)

greetings  :Smile: 

----------

## manny15

I can't seem to get RC_PARALLEL to work. I've set RC_PARALLEL_STARTUP="yes" in the file /etc/conf.d/rc

, rebooted, and noticed no difference.

----------

## tomthewombat

If your computer started up, then it must be working!  I have had it lock up on me in several cases.

----------

## tomthewombat

the CKO patchset has Reiser4 built in.  If you don't need all his extras he posts the reiser4-cko patches.

----------

## DocterD

how can i reverse Bootsplash?

----------

## Tuti

get the ck4 bootsplash patch from con's site at :

http://ck.kolivas.org/patches/2.6/2.6.7/2.6.7-ck4/split-out/bootsplash314.diff

then do "patch -R"

and then apply the bootsplash-sp2 patch from : 

http://www.bootsplash.de/files/bootsplash-3.1.4-sp2-2.6.7.diff

it worked like a charm for me -  got my bootsplash working @85Hz without even compiling vesa in the kernel

----------

## kerframil

Hello chaps. Well Con has just released 2.6.7-ck5.  :Very Happy: 

I've filed a request for it to be bumped (which contains more details about the release).

Some of you will probably be pleased to note that this release contains bootsplash-3.1.4-sp3 so there is no longer any need to manually update the bootsplash implementation.

----------

## kerframil

As per a similar post I made on another ck related thread, if anyone is interested in the future performance of 2.6 kernels with regard to desktop performance and has some time to spare for testing, then please have a quick look at this thread. Thanks.

----------

## neophyte46

ok, i've started threads of my own which haven't really been answered. I'm on a love7 kernel at the moment. I was on a ck2. I've noticed a bit of hype in the new ck5 (looks like a fair bit has been added). I have downloaded the 'patch-2.6.7-ck5' but don't know hot to use it. i.e. patch the kernel.

I'm a noob when it comes to patching kernels. Would love to give ck5 a go. Can  you on you ck gurus please elaborate a little so I can jump on the ck5 bandwagon and see what it's all about.

Cheers,

----------

## barry

ck5 is in portage now, though it's still ~x86. If you want to patch manually, just extract the vanilla kernel, cd into the top level directory, and run

```
# bzcat /tmp/patch-2.6.7-ck5.bz2 | patch -p1
```

Check Con's website at http://kernel.kolivas.org. The main changes from vanilla are the staircase scheduler and VM autoregulation (currently being tested as above). The CK patches are a lot more stable than love, as love is an unstable patch set on top of an unstable large base patchset (the -mm tree).

----------

## Gentii

Does anyone really notice a difference between vanilla 2.6.7 and a 2.6.7-ck kernel ? With or without benchmarks ?

----------

## neophyte46

 *barry wrote:*   

> ck5 is in portage now, though it's still ~x86. If you want to patch manually, just extract the vanilla kernel, cd into the top level directory, and run
> 
> ```
> # bzcat /tmp/patch-2.6.7-ck5.bz2 | patch -p1
> ```
> ...

 

I'm not exactly sure what you mean by this. In portage the only vanilla sources I sore were 2.4.* Unless you reffering to the 2.6.7-r2 ck-sources.

You said the ck5 is in portage now. Didn't show up for me. Is it masked? I have '~x86' in my accept keywords declaration.

If indeed you are to apply the ck5 to the 2.6.7-r2 ck-sources it didn work for me. So i'm not sure what I did wrong. Though I'm prolly not even on the right track. Anyway, it said that there was already a patch applied. Then I just tried to keep going, it would patch some stuff, then say s couple of blocks failed etc.

----------

## neophyte46

my apologies. I forgot to rsync portage. I can see it now. I'll emerge it

Though I would still like to know the process of applying a patch manually.

----------

## kerframil

 *neophyte46 wrote:*   

> I'm not exactly sure what you mean by this. In portage the only vanilla sources I sore were 2.4.* Unless you reffering to the 2.6.7-r2 ck-sources.

 

For historical reasons, vanilla 2.6 sources are considered to be sys-kernel/development-sources. Correspondingly, sys-kernel/gentoo-dev-sources is the gentoo patched 2.6 kernel (which isn't much different actually).

 *neophyte46 wrote:*   

> You said the ck5 is in portage now. Didn't show up for me. Is it masked? I have '~x86' in my accept keywords declaration.

 

Yes, it was committed to portage recently. You will know if it's in your tree by checking for the existence of /usr/portage/sys-kernel/ck-sources/ck-sources-2.6.7-r5.ebuild. If it isn't there then it may not have propagated to the mirror(s) that you tend to sync from yet. Having said that, by the time I write this it should be everywhere.

I don't want to stray too far from the beaten track, but please don't use ACCEPT_KEYWORDS. It's a bad idea for a lot of reasons. Instead, do this:Create a file called /etc/portage/package.keywords if it doesn't already exist (creating the parent directory also if necessary)Insert this line into the file:

```
sys-kernel/ck-sources ~x86
```

Now you can emerge the latest version of ck-sources simply by typing

```
emerge ck-sources
```

Furthermore, the sources will never be downgraded.

 *neophyte46 wrote:*   

> If indeed you are to apply the ck5 to the 2.6.7-r2 ck-sources it didn work for me.

 

And that's hardly suprising, most patchsets should be applied to the base on which it was developed - that's plain, vanilla 2.6.7 sources in this case  :Wink: 

I think you would find it considerably less confusing if you stick to using ebuilds for managing your sources for the time being. Nonetheless I shall provide a step-by-step example of how to prepare a 2.6.7-ck5 tree.

```
# cd /usr/src

# tar xjfv /usr/portage/distfiles/linux-2.6.7.tar.bz2

# chown -R root:root linux-2.6.7

# wget http://ck.kolivas.org/patches/2.6/2.6.7/2.6.7-ck5/patch-2.6.7-ck5.bz2

# cd linux-2.6.7

# bzcat ../patch-2.6.7-ck5.bz2 | patch -p1

# cd ..

# mv linux-2.6.7 linux-2.6.7-ck5

# rm linux

# ln -s linux-2.6.7-ck5 linux
```

A few assumptions are made above (you're running as root, you don't already have some vanilla sources residing at /usr/src/linux-2.6.7 ...) but I hope you get the idea. The purpose of bzcat is that it outputs the decompressed contents of the bzipped ck patch which are then piped into patch on the fly. Often you may deal with patches which aren't compressed in which case the patch command looks more like this:

```
patch -p1 < /path/to/foo.patch
```

The purpose of -p1 is to strip the first part of the pathname referenced in the patchset itself. Read the first several lines of the patch with the less command (you don't have to bunzip it, less is bz2 aware). You can see that Con was working on two trees, linux-2.6.7-ck.orig and linux-2.6.7-ck. What this basically means is that he starts with a fresh copy of 2.6.7 sources and duplicates the tree. He folds his patches into the duplicated tree and later uses a recursive diff command which determines what the differences are which duly generates a patch. It's not a complicated procedure once you know how.

If you didn't use the -p1 parameter then the following would be the case:You'd have to be in /usr/src while applying the patch, not in the directory containing the sourcesYour initial source tree containing the vanilla 2.6.7 sources would have to be called linux-2.6.7-ck.orig which, let's face it, is unlikely  :Wink: 

HTH.

----------

## neophyte46

Okay, thanks kerframil. That cleared basicaly everything up. Thanks a lot for taking the time to write that. Helped a lot. As stated above I forgot to update portage (oops   :Embarassed:  )

But i'm going to try patching a kernel from scratch just cos I wanna know how to do it. So i'll print this little post out so I don't lose it.

I guess this is as good as any place to do it.

I gather that pre-emption is to be turned off with this kernel. If so, (which I have actually done) why is it enabled by default?

Cheers,

----------

## kerframil

 *Gentii wrote:*   

> Does anyone really notice a difference between vanilla 2.6.7 and a 2.6.7-ck kernel ? With or without benchmarks?

 

Yes. I can honestly say it's transformed my desktop experience with Gnome 2 on a PIII 733Mhz with a none-too-impressive specification. Applications also start faster; there are very valid technical reasons for that. If you hunt around for Con's original "whitepaper" on his so-called orthogonal patches (a.k.a O21.int, the interactivity work which made it mainline during the 2.6-test series) he goes into great detail about how the new scheduling algorithms could have the drawback of making application load times longer (which they did). The approach of the staircase scheduler is sufficiently different that it does not suffer from the same characteristic. Incidentally, I remember that the interactivity of the 2.6 kernel was absolutely appalling before Con developed his O21.int patches - worse than 2.4 in my view. He did us all a great service then (notwithstanding Nick Piggins' work which doesn't measure up to the claims anymore, in my view).

Benchmarks are all well and good, but most of them are oriented towards measuring throughput. I don't know of any benchmark that could feasibly measure how "sensible" scheduling decisions are from the perspective of human interaction. Sometimes I want certain things to be deferred, and other things to be a given a higher priority if it makes things "feel" faster. And often, such descisions have a slight cost to overall throughput; consider pre-empt for example. The bottom line is that, for a desktop, I simply don't care as long as performance remains within acceptable boundaries and I can get my work done more quickly because of the greater level of interactivity!

Maybe you wouldn't notice anything on a high-spec machine. All I can say is that I've been using Linux for a fair few years now on a variety of systems, with various kernels, patchsets and all the rest of it. This is the most satisfactory experience I've had thus far from the point of view of desktop useage. If it were not having any apparent effect to me, then I would stick to mainline - seriously.

----------

## kerframil

 *neophyte46 wrote:*   

> Okay, thanks kerframil. That cleared basicaly everything up. Thanks a lot for taking the time to write that. Helped a lot. As stated above I forgot to update portage (oops   )

 

No problem.

 *Quote:*   

> I gather that pre-emption is to be turned off with this kernel. If so, (which I have actually done) why is it enabled by default?

 

That's your call, there is nothing to specifically stop you from enabling it. My explanation is as thus: back in the 2.4 days the kernel exhibited numerous deadlocks, code paths which exhibited long held locks (which couldn't be broken) and areas of high latency in general. Let's get one thing straight: the idea that the kernel is only pre-emptible if the CONFIG_PREEMPT option is enabled is a complete myth. However, CONFIG_PREEMPT does allow user-space processes to interrupt (or pre-empt) in-kernel processes at specific points where it would not otherwise have been possible.

The problem is that this also adds some overhead and additional complexity. Also, the 2.6 kernel has competent latency levels in general - in that sense it is a massive improvement on 2.4. In my opinion, CONFIG_PREEMPT should not be enabled for general desktop usage. I believe it has gotten to the point where it makes performance worse. It's probably still OK for those who absolutely must maintain predictable latency levels - pro audio work, JackIt users and a few other things.

Why is it enabled by default? Good question. I have a sneaking suspicion that it is partly political, a lot of work went into the pre-empt effort ... maybe I'm being a little too suspicious though  :Wink: 

Another explanation could be that the people who maintain and control such things simply have little inclination or time to do something as trivial as overhaul the explanation of CONFIG_PREEMPT and whether it is set by default or not in defconfig!

My belief is that there are better approaches now for reducing the lesser remaining areas of latency in the 2.6 kernel. For instance, Ingo Molnar is working on a latency reduction patch which is similar in principle to the low-latency 2.4 patches of old. In fact, if you are interested in playing with patches you should really take a look at the ck mailing list and look at some of the patches he has floating around in his 2.6.7-bk20 directory (it's experimental stuff though, so be warned - and it has to be applied to the latest -bk20 bitkeeper checkout of the 2.6.7 kernel).

Furthermore, Con maintains the latest instance of his ck patchset agains vanilla kernels under 2.6.7-ck-dev at all times. This has a few improvements over the official -ck5 patchset: a tiny staircase micro-optimisation and a bundle of CFQ elevator fixes from Jens Axboe.

EDIT: I notice that Nick Piggin has been doing futher maintenance on his patchset, so I'll probably give it a whirl just to see how his approach to interactivity is doing now and to make sure my convictions are fair. I remember it being pretty good at one point during the 2.6-test series, but I found Con's orthogonal (and eventually, staircase) work to be better in the long run. I also do not like the idea that one has to renice X to -10 to get good interactivity. Anyway, his patch is here.

----------

## Lucho[FLCL]

 *Quote:*   

> Also worthy of note is the addition of ability to configure CONFIG_HZ (that's the frequency of the timer which controls the task scheduler). This used to default to 100Hz in 2.4 (providing a maximum granularity of 10ms for a single scheduling "slice") and was rasied to 1000Hz in 2.6 (providing a granularity of 1ms). Users of slower systems might find it beneficial to reduce the frequency (see Con's page for details). Those who are interested in throughput - servers, heavily stressed workstations, computational clusters - might prefer 100Hz. However, if you take the route of altering the default then be sure to evaluate the effect on performance carefully. The scheduler may well be generally tuned to behave better at 1000Hz. 

 

I have a 550Mhz PIII, and tried 2.6.7-ck5 with CONFIG_HZ=500, and I didn't like how it behaved. I recompiled with CONGIG_HZ=1000 and works muuuuuch better, specially under heavy workloads...YMMV

----------

## kerframil

 *Lucho[FLCL] wrote:*   

> I have a 550Mhz PIII, and tried 2.6.7-ck5 with CONFIG_HZ=500, and I didn't like how it behaved. I recompiled with CONGIG_HZ=1000 and works muuuuuch better, specially under heavy workloads...YMMV

 

Interesting ... I'm not entirely suprised though. There used to be a general rule going around that, if you are going to alter HZ, then ideally it shouldn't be any higher than 1/2 of the CPU speed. In light of the many changes that have occured in the kernel (the switch to 1000Hz, the O(1) scheduler and scheduling algorithms/policies) I doubt the advice is too relevant now - at least for desktop users. Thanks for the feedback.

----------

## Lucho[FLCL]

 *kerframil wrote:*   

>  *Lucho[FLCL] wrote:*   I have a 550Mhz PIII, and tried 2.6.7-ck5 with CONFIG_HZ=500, and I didn't like how it behaved. I recompiled with CONGIG_HZ=1000 and works muuuuuch better, specially under heavy workloads...YMMV 
> 
> Interesting ... I'm not entirely suprised though. There used to be a general rule going around that, if you are going to alter HZ, then ideally it shouldn't be any higher than 1/2 of the CPU speed. In light of the many changes that have occured in the kernel (the switch to 1000Hz, the O(1) scheduler and scheduling algorithms/policies) I doubt the advice is too relevant now - at least for desktop users. Thanks for the feedback.

 

You are welcomed.

My guess is that, by enlarging the quantum of the RR scheduler (time slice), you affect the degree of multiprogramming (less programs do more). And taking into account that you always have spare cpu cycles (even in "slow" cpu's like mine) , having smaller time slices should assure better CPU utilization when having lots of processes running, despite the higher overhead (low in O(1), dunno in staircase).

Having said that, Kon is supposed to know more than me, so I won't say that he's lying. I say that I feel better with 1000, and that's all.

----------

## kerframil

There is now an apparently stable snapshot of -ck5 against the 2.6.8-rc1 branch. Some very exciting work has been going on with regard to fixing areas in the kernel which cause high scheduling latency. Please see this topic to find out more.

----------

## sofcik

Hi!

I have switched to ck from love, and i'm realy impressed how good it works  :Very Happy: 

Now i can realy use  wine and winex with full performance.

But only one thing i can't do myself is to configure resolution and refreshrate for my console.

Can you show me an example how to make 1280x1024 with 85Hz with and without bootsplash. And is that possible to use nvidiafb or not.

I'm sorry for being a noob. :Wink: 

----------

## DocterD

2.6.7-ck6 is released

----------

## charlieg

 *DocterD wrote:*   

> 2.6.7-ck6 is released

 

With 2.6.7-ck5, I was having some horrendous problems; there were "conflicts" with cfq when it came to scheduling.  It was, for example, taking 20-30s to swap almost any app out of swap and strangely apps were going into swap fairly needlessly.  These issues all seem fixed in ck6.

One thing I have noticed with the all the ck sources I've used lately is that my glxgears fps results are more than half of the love-sources results.  About 500-600 fps with the latest ck, and the last love gave a steady 1320 fps.  Although I'm unsure whether more involved 3d apps suffered.

----------

## Halcy0n

Staircase is also in mm-sources as of 2.6.8-rc2-mm2.  I'm running it right now and it seems very nice.

----------

## DocterD

dunno if it is CK related, but with CK6 the Video Playback is to fast.

----------

## wrc1944

I'm also running 2.6.8-rc2-mm2, and find it excellent. I still have:

CONFIG_PREEMPT=y

Maybe I'll recompile without it. Any feedback on the differences in real world terms?

On a previous ck kernel, I patched with staircase, and there was an option for it in xconfig towards the end (IIRC, under kernel hacking), but then it isn't showing up in the kernel config file after installation. However, I no longer see this option in rc2-mm2 when doing xconfig, or the last 2 ck full versions I've done. Is staircase really being applied, and it's now just an integral part of the kernel, with no config option? I use CFQ scheduler under General Setup.

CONFIG_IOSCHED_CFQ=y

wrc1944

----------

## barry

Practically everybody (including kernel developers) recommends leaving kernel preemption off in the 2.6 series; apparently it will reduce performance.

The staircase code replaces the default scheduler, it's not selectable like the IO scheduler - it's definitely there though!

----------

## Pink

 *wrc1944 wrote:*   

> Is staircase really being applied, and it's now just an integral part of the kernel, with no config option? I use CFQ scheduler under General Setup

 

As the last post said, and I will try to reinforce - they are two different types of scheduler.

The one that is selectable is the IO scheduler (you can choose cfq, deadline, anticipatory, etc).

You cannot choose the compiled in CPU scheduler, the standard scheduler is known as the  O(1) which is adequate for low end desktop use but does suffer under load this is where other cpu schedulers come in: ck sources uses what is known as the staircase scheduler (see google for more information), there are, of course, others you may choose to be compiled in to the kernel (but only one at a time) such as Nick Piggin's scheduler (np) and so on.

In case you were wondering why the standard scheduler is used when there are better options - well, that is something being looked at, staircase is being tested in the latest mm release and, as Andrew Morton says, will not stay there, they will also try other schedulers and see if/how the standard one can be improved. Also, don't get me wrong, the O(1) is not bad, it just lags a bit under load.

It is a common error that people make but they are entirely seperate entities and do different jobs (although like all aspects of the kernel they are interlinked).

Again, google is a good one to find out how they work and how they are different.

HTH   :Very Happy: 

----------

## wrc1944

PickledOnion,

Thanks for the explanation:

I was aware of they are different, as Redeeman (IIRC) had previously clued me in a few weeks ago. I have read quite a bit on this subject, and tested the different IO schedulers, and it seems for me on my desktop boxes, with my usage parameters, CFQ gives the best perceived performance.

barry wrote:

 *Quote:*   

> 
> 
> The staircase code replaces the default scheduler, it's not selectable like the IO scheduler - it's definitely there though!
> 
> 

 

I can't explain this, but in previous make xconfigs, when I had applied staircase as an individual patch (not as part of a full ck snapshot), an option for staircase did appear,and could be enabled/disabled. But then when you look at the resulting config file, I'll be damned if I can find a line referencing it.  Anyway, I'll try no preempt with my next kernel, later today.

Thanks for the input,

wrc1944

----------

## wrc1944

Just checked, and 2.6.8-rc3-mm1 is out. Sure enough, staircase is dropped. From the new mm1 changelog:

 *Quote:*   

> Dropped the staircase scheduler, mainly because the schedstats patch broke it.
> 
> We learned quite a lot from having staircase in there.  Now it's time for a new scheduler anyway.
> 
> 

 

Staircase works good for me, so I'm not sure about this. Can somebody expain a little about exactly what schedstats is, or does? I assume it means "schedule statistics"? Is this really the end of staircase in mm kernels, and I suppose eventually mainline, and only ck kernels will use it.

wrc1944

----------

