# 2.6.7-ck1 is out

## gringo

http://lkml.org/lkml/2004/6/16/56

no reiser4 this time  :Crying or Very sad:  , but looks great anyway !

----------

## genstef

hi,

I heard ck is only good for pentium4, is this true?

And is it for amd users better to stick to vanilla, mm or love?

----------

## gringo

I never used an amd with ck, but i heard ck is very nice on non-pentium cpus too.

The best tip i can give you is to try both, love and ck, and then stay with the one that works better in your system!

----------

## Manco

How can I apply those patches to the kernel, can somebody please make a step-by-step guide of howto apply these ck patches to the kernel ?

thanks

----------

## genstef

For everyone that needs it bootsplash-patches can be found at www.bootsplash.de

----------

## gringo

thats quite easy :

- download linux-2.7.6.tar.bz2

- donwload patch-2.6.7-ck1.bz2 

copy linux-2.6.7.tar.bz2 to /usr/src and unpack it:

```

cp linux-2.6.7.tzr.bz2

tar -xvjf linux-2.6.7.tar.bz2

```

Now you will see a new directory called linux-2.6.7. Copy Con´s patch to this directory and patch the kernel sources:

```

bzcat patch-2.6.7-ck1.bz2 | patch -p1

```

Adjust the kernel conf to your needs, recompile the kernel, add a new boot option to your bootloader, reboot and enjoy !

Happy compiling   :Wink: 

----------

## Manco

 *gringo wrote:*   

> thats quite easy :
> 
> - download linux-2.7.6.tar.bz2
> 
> - donwload patch-2.6.7-ck1.bz2 
> ...

 

Thanks alot !

----------

## silicondecay

www.kernel.org

Download the entire 2.6.7 kernel. And its not vulnerable to that new exploit! Woohoo.

Although, run the exploit, and you get a bunch of neat stuff scrolling down your screen

----------

## kerframil

 *genstefan wrote:*   

> I heard ck is only good for pentium4, is this true?

 

Not in the slightest. That hearsay originates from a hackish attempt to make the scheduler SMT aware (i.e. hyperthreading friendly) circa 2.6.4-ck I believe. This is old news, and 2.6.7 vanilla features a far more developed option for such purposes (CONFIG_SCHED_SMT).

 *Quote:*   

> And is it for amd users better to stick to vanilla, mm or love?

 

The processor in use should (generally) have absolutely no bearing over your choice of kernel. For overall speed I'd suggest sticking to -mm, partly due to the countless fixes and improvents it inevitably contains. However, I would not normally make a point of recommending -mm to someone who is confused by the array of kernel patchsets on offer! It is also frequently a playground for untested code (which can cause problems, breakage and even performance regression in specific areas at times).

The bottom line is that 2.6.7 is one of the finest releases yet (numerous bugfixes/improvements, not to mention Andrea Archangeli's object-based RMAP VM alterations for reduced memory useage and greater scaleability). So vanilla would be a fine choice. The -ck patch is very lightweight now and the only major change it makes is to apply a different scheduling policy (the so-called "staircase" scheduler). I wouldn't assume that the staircase scheduler is automatically going to be make everything run like greased lightning simply because it's new and sounds cool, but it is definitely worth trying out. One of the more noticeable effects should be reduced application startup times.

Personally - and I have no intention of confusing the issue further  :Wink:  - if I were looking for a nice desktop-oriented kernel at this point I would be running what would effectively be 2.6.7-ck without the staircase scheduler and with bootsplash added. I'd also apply SuSE's writeback latency patch and avoid using pre-empt (which is hyped beyond belief). In fact, that's not entirely dissimilar to how gentoo-dev-sources manifests itself, so keep your eye out for future releases.

EDIT: I'd also add elevator=cfq as a bootloader option for the kernel, because the CFQ-4 I/O scheduler has been in 2.6 for quite a while now and is well suited for desktop I/O loads (where fairness is important).

----------

## AlterEgo

Kerframil, i agree with most of your comments (as usual, your comments are of very high quality), but what's your 'problem' with staircase?

Vanilla 2.6.7 without pre-empt and with cfq is way less responsive than 2.6.7.-ck1 with staircase enabled IMHO.

----------

## kerframil

 *AlterEgo wrote:*   

> Kerframil, i agree with most of your comments (as usual, your comments are of very high quality), but what's your 'problem' with staircase?

 

Nothing per se. I have the utmost respect for Con's work and, indeed, I am looking forward to trying out the latest incarnation of the staircase policy. My intention was to sound a minor warning note against the untempered expecations which we are all prone to at times when it comes to new features and methodologies, sometimes without considering the prospect of any downsides, or even conducting the most basic comparative against the default behaviour! For instance, I know that staircase had distinct problems with processes that exhibited the priority inversion syndrome at one point; in particular mplayer required a minor alteration to work effectively.

I'm not saying that's still the case, that it's of earth-shattering importance or in any way trying to suggest that there is a "problem" in staircase. Rather, I'm just asserting my belief that, if feasible, one should start with a vanilla-ish base and branch out from there - particularly if one is (a) not massively experienced with kernels (b) yet, hungry for more and eager to play! At least it provides a means for even the simplest comparative. Perhaps it didn't come across as such, but I assure you that that's what I meant  :Wink: 

 *Quote:*   

> Vanilla 2.6.7 without pre-empt and with cfq is way less responsive than 2.6.7.-ck1 with staircase enabled IMHO.

 

I don't doubt this and as I said, I look forward to trying the latest instance just as soon as I get a moment to do so  :Smile:  One thing I'm curious about though: you explicitly make a reference to preempt and cfq without stating whether those two options were effective in your -ck setup! Surely the reference is spurious then? (I'm assuming that you had the same setup in both cases, in which case it's a very fair observation that the staircase scheduler is clearly working some magic!) Actually, now I think of it - ck actually had a policy of setting CFQ as the default elevator (rather than AS) at one point. I haven't checked to see if that's still the case in 2.6.7-ck yet.

EDIT: Futhermore, my suggestion for a desktop-oriented kernel was clearly maked as "personal", and that's very much on the pretext that I haven't tested the latest -ck work yet (which perhaps I should have made clear)  :Wink: 

----------

## AlterEgo

 *kerframil wrote:*   

> [...]

 

I directly compared vanilla without preempt and with cfq with an identical .config using 2.6.7-ck1.

The difference is response is awsome (do try it; it's worth the effort) , without the obvious drawbacks that the earlier staircase schedulers had (problems with parallell startup scripts, severy problems with java/nptl and especially troubles @ high load) .

 I absolutely share your view that it's better to change just one or two parameters when comparing performance between kernel (which, I believe, I did in this case, because 2.6.7-ck1 is quite clean compared to other patchsets ), than to change too many things at once (which is what I don't like about love-sources, or -mm (no flame intended)).

 *Quote:*   

> 
> 
> writeback latency patch 
> 
> 

 

Why is this one interesting to you?

----------

## kerframil

 *AlterEgo wrote:*   

>  *Quote:*   
> 
> writeback latency patch 
> 
>  
> ...

 

It forces a conditional reschedule at two points in the kernel where long held locks are known to occur. 2.6 has vastly improved on the latency front since the days of 2.4 (which is one of the reasons why in-kernel preemption is less important now) but there are still a couple of areas that could be improved.

Takashi Iwai performed some serious profiling on the kernel and asserted that 90% of 2.6 latency issues were solved by a strategically placed cond_resched() in mpages.c (which was accepted by Andrew Morton). The rest of his efforts are in the aforementioned writeback-lat patch. Amazingly, Andrea's 2.4 branch actually exhibited a better worst-case max latency scenario than 2.6 ... that is, until Takashi came up wih these alterations.

An interesting point here is that preemption cannot usefully occur while a lock is held, so really preemption does nothing to reduce the worst-case latency. Instead, it provides more consistent average latency times overall (which is very important for some domains such as realtime audio processing and such) but let there be no doubt that in-kernel preemption carries some very real overhead of its own.

See this kerneltrap thread for a treasure trove of information on the topic. I believe this patch to be quite effective and have not missed preempt one iota since turning it off (I'd definitely still use it on 2.4 though). It is also included in Andrea's patchset (a man whom I respect a great deal), and SuSE's patchset (which I think is possibly the greatest and best engineered kernels to be found in any of the major distros). That only serves to reinforce my trust in this patch - which is also to be found in gentoo-dev-sources (albeit in a formative incarnation until the next release of these sources). Basically, I tend to side with Andrea regarding preempt in that he believes that it shouldn't be constantly active throughout the kernel, rather it should be activated in certain paths where it actually makes sense.

I've also suggested to Con that he might consider the writeback-lat patch for inclusion in his patchset. It will be interesting to see what, if anything, his opinion turns out to be on the matter. He has gone on record as saying that he didn't think it was really necessary for CONFIG_PREEMPT to default to Y anymore, which in itself is interesting.

----------

## Cerement

ebuild:

```
# Copyright 1999-2004 Gentoo Technologies, Inc.

# Distributed under the terms of the GNU General Public License v2

# $Header: $

UNIPATCH_LIST="${DISTDIR}/patch-${KV}.bz2"

K_PREPATCHED="yes"

UNIPATCH_STRICTORDER="yes"

K_NOUSENAME="yes"

ETYPE="sources"

inherit kernel-2

detect_version

DESCRIPTION="Full sources for the Stock Linux kernel Con Kolivas's high performance patchset"

HOMEPAGE="http://members.optusnet.com.au/ckolivas/kernel/"

SRC_URI="${KERNEL_URI} http://ck.kolivas.org/patches/2.6/${KV/-ck*/}/${KV}/patch-${KV}.bz2"

KEYWORDS="~x86 ~ppc"
```

----------

## swimmer

 *Cerement wrote:*   

> ebuild:
> 
> ```
> # Copyright 1999-2004 Gentoo Technologies, Inc.
> 
> ...

 

Thanks a lot  :Smile: 

Stefan

----------

## dan2003

I did the above, made a 2.6.7-ck1 overlay ebuild, emerged, patched with bootsplash and suse patch. Boot splash causes system to hang during boot though  :Sad: 

----------

## dan2003

Hmmmm. seems to be fb rather than bootsplash causing the issues

----------

## dan2003

Wow, Resume from "echo 4 > /proc/acpi/sleep" works with this kernel on my HP/compaq nx9005. All i had to do was restart hotplug to get my usb mouse back up and rmmod/insmod the natsemi module to make the networking go again.

Edit: However "echo 3 /proc/acpi/sleep" fails - form dmesg:

```

PM: Preparing system for suspend

Stopping tasks: =============================================================|

eth0: remaining active for wake-on-lan

Could not suspend device 0000:00:02.0: error -5

ACPI: No IRQ known for interrupt pin A of device 0000:00:10.0

eth0: Setting full-duplex based on negotiated link capability.

Restarting tasks... done

```

the device mentioned is

0000:00:02.0 USB Controller: ALi Corporation USB 1.1 Controller (rev 03)

Aslo lots of :

```
0 [usbcore]

 [<cca0140c>] usb_disable_device+0xcc/0xf0 [usbcore]

 [<cc9fbcd6>] usb_disconnect+0xc6/0x110 [usbcore]

 [<cca04409>] usb_hcd_pci_remove+0x89/0x190 [usbcore]

 [<c01da7bb>] pci_device_remove+0x3b/0x40

 [<c021d234>] device_release_driver+0x64/0x70

 [<c021d260>] driver_detach+0x20/0x30

 [<c021d50b>] bus_remove_driver+0x5b/0xa0

 [<c021d98a>] driver_unregister+0x1a/0x46

 [<c01daa26>] pci_unregister_driver+0x16/0x30

 [<ccaab12f>] ohci_hcd_pci_cleanup+0xf/0x13 [ohci_hcd]

 [<c012ae1f>] sys_delete_module+0x15f/0x1d0

 [<c01441c0>] do_munmap+0x130/0x180

 [<c0105efb>] syscall_call+0x7/0xb

```

 from dmesg :/

Shame speedfreq now doesnt work  :Sad:  and like a pointed out above theres a problem with fb.

----------

## Gentii

Strange, I didn't have any problem with fb on this laptop.

But I'll try the sleep thingy, it's great if it works on 2.6.7  :Smile: 

----------

## venkat

one critical bub somewhere...my atmel based usb wlan driver (berlios one) freezes the kernel hard. it doen't even boot with the device in. hangs when the driver gets hotplugged. i'm sure it's something to do with the ck1. 2.6.7_rc2-love2 runs fine. all the prev loves worked too. i'll wait until ck2 gets released.

----------

## dan2003

K, I have sorted the speedfreq issue, Has the modules name changed? all i had to do was add cpufreq_userspace to /etc/modules.autoload.d/kernel-2.6 but i don't remember needing to do this before!

I also have fb and bootsplash working, i specified video=vesafb:ywrap,mtrr as well as vga=791 which is all i had before. I'm going to investigate using the radeon driver instead.

I also got dri working in Xorg (IGP320m) and can play q3demo again apart from the online server appears to be down  :Sad: .  

SO i think i have more working than ever before now on my laptop,

However have issues on my desktop machine.

The usb keyboard doesn't work past hotplug loading where the legacy usb gets overriden (i assume) and i get all kinds of nasties from dmesg (theres a comment "irq 5  nobody cared" and then there a line saying ignored). So, i plug in the pS/2 keyboard and have a play, 

Try to rmmod ohci-hcd and rmod hangs, cannot safely reboot either, the reboot script seems to die whilst trying to rmmod ohci-hcd, Just to really annoy me the manufacturers of this damn ps/2 keyboard decided that they would do away with the sysrq button whilst adding about a zilion silly this that the other "internet buttons".

Built the nvidia driver from the nvidia install script and X starts, however have hard lockup when i try to switch from X to  vt, (ctrl+alt+blah)

----------

## wizard69

works fine here 

```

2.6.7-ck1 #1 Thu Jun 17 16:59:49 CEST 2004 i686 AMD Athlon(tm) XP 3200+ AuthenticAMD GNU/Linux

```

i also have bootsplash working with the new patch from bootsplash.de

----------

## borkdox

Sorry to say this, but 2.6.7-ck1 is much slower than 2.6.7-rc3-love1. I have like 20 FPS less in UT2004 using 2.6.7-ck1. Could be Staircase sched, so I might try without it.

----------

## sendai

 *venkat wrote:*   

> one critical bub somewhere...my atmel based usb wlan driver (berlios one) freezes the kernel hard. it doen't even boot with the device in. hangs when the driver gets hotplugged. i'm sure it's something to do with the ck1. 2.6.7_rc2-love2 runs fine. all the prev loves worked too. i'll wait until ck2 gets released.

 

Arrrrr! I've the same problem with my atmel pcmcia: with 2.6.5 kernel everythings goes well but with 2.6.6 and 2.6.7 won't works...   :Mad: 

see also 

http://www.uwsg.iu.edu/hypermail/linux/kernel/0405.1/0599.html

http://thekelleys.org.uk/atmel/READ-ME.linux-2.6.6

http://thekelleys.org.uk/atmel/READ-ME.linux-2.6.7

----------

## kerframil

 *elocal wrote:*   

> Sorry to say this, but 2.6.7-ck1 is much slower than 2.6.7-rc3-love1. I have like 20 FPS less in UT2004 using 2.6.7-ck1. Could be Staircase sched, so I might try without it.

 

Most of the "goodness" in Love is derived from the fact that it's based on -mm IMHO. So I don't think the comparison is very fair - Andrew Morton's kernel contains a significant body of work from highly skilled, high-tier kernel developers which often significantly enhances performance; and is always synced up to Linus' personal tree among other things. That can work both ways though, sometimes -mm breaks things or actually causes performance regression within specific domains.

Con now makes an effort to keep a version of his patchset against -mm, I believe you can get patches for 2.6.7-mm6 from here but you'll have to apply each one manually according to the order specified in the series file.

Also consider that using isochronous scheduling for games is a bad idea (his website erroneously claimed that it was a good thing, I don't know if he's fixed that yet). Also, games often benefit from having positive nice values (i.e. lower priorities) believe it or not - at least with the staircase scheduler.

I don't track love much, but I used to use Nick's scheduling policy (does love still use that?) and found it to be inferior to Con's work the last time I tried (it was great back in the early 2.6-test days though).

PS: 2.6.7-ck5 should be in portage within the hour, and the staircase scheduler had a lot of work done on it between -ck1 and -ck4.

----------

