New Kernel Speed up Patch File from Mike Galbraith?

James, here How would I apply the Phoronix patch? is a post by brian_j that explains it all.
Thank you Knurpht, I shall read through it and see if I can understand the procedure. It looks like I will be spending a lot of time this weekend cleaning up the house in preparation for Thanksgiving Day, a big deal next to Christmas here in the USA. My son and daughter-in-law (whom is expecting their second child) and my only Grandson are coming to visit us this week. So, I am not sure if I will be able to do a lot with kernel compiles, but I guaranty I will read the whole thread through and through, perhaps even tonight.

Thank You,

Has anyone been able to adapt this alternative approach to openSUSE for playing around with ?

I (think) I was able to apply this to a session running on a Fedora-14 LXDE liveCD. I applied the ‘Ubuntu’ patch to Fedora, and “subjectively speaking” the running session response does appear much snappier. Although I’m not experienced with Fedora, and this was a liveCD session, so its very very difficult to be certain I was not just dreaming.

I confess I don’t know how to apply this to openSUSE, … as there are differences in how the various files are located on Fedora, Red Hat, and Ubuntu.

Working/studying on it right now. Already found out that kernel-default is needed, made the switch 5 minutes ago. I’ll keep you posted.

In hindsight, this was not correct , … and rather there is Fedora guidance here. However that is not applicable to openSUSE, where at least one of the reasons being there is no rc.local in openSUSE.

I note an old post here, where suggestions to use boot.local are possibly wrong, as boot.local is run after the boot.* scripts but BEFORE any runlevel scripts. Whereas rc.local is normally run after the runlevel scripts. I don’t know if that matters, and one may be required to create a proper init script. (purported there are some skeleton scripts in /etc/init.d/ that one can use as a basis for an init script, however the reading is rather heavy going).

Another complication is ‘cgroup’ is handled differently in openSUSE, … signficantly different from what I can see. … I don’t know of an equivalent here.

I note a comment in SLES that says:

Memory controller (cgroup) is disabled by default

Memory cgroup is runtime-disabled by default in SUSE Linux Enterprise Server 11 due to speed regressions introduced by this facility. Please pass “cgroup_enable=memory” to the kernel commandline to have this enabled.
I wonder if that is applicable to openSUSE ?

It looks like this option has been committed to be removed from openSUSE.

And on a different note, I note an openFATE feature suggestion (to restore cgroup): https://features.opensuse.org/309618

Here’s what I did after some studying on the alternative way to effect this:

I added “cgroup_enable=memory” to the boot options

I followed the instructions for Ubuntu for the alternative, used /etc/init.d/boot.local instead of /etc/rc.local, since /etc/rc.d is a symlink to /etc/init.d/ (hadn’t read oldcpu’s findings by then).

It all seems to work, but how do I find out if it works :). My laptop is already fast thanks to the SSD.

Mind, this is about the mentioned alternative for the kernel patch.

Thanks. If I get the chance, I’ll try this tomorrow on one of my 32-bit PCs.

If this does work, we need to convince as many people as possible to vote for this openFATE feature suggestion (to restore cgroup): https://features.opensuse.org/309618.

The cgroup_enable=memory is being removed from the openSUSE kernel, and we need to get it put back in (if this works).

It appears I’m confused on this … it was put in the openSUSE-11.3 kernel, and the comitt appears to now remove it from future kernels ? … In which case a new openFATE submission may be needed.

Any number of software mistakes can make you reach for the backups, not just kernel patches. So it goes without saying that you don’t do this on any machine you count on daily, i.e. not your workhorse. You do it on a dispensable machine.

Yes, I’m sure some pedant will point out that you can destroy hardware with malfunctioning software. The point is that it far easier to destroy hardware experimenting with hardware.

Personally I’m sure that eventually some variant of the patch or alternative will go mainstream. I’m satisfied with the interactive response at the moment so I’ll just wait. It’s amusing to watch the second and third hand commentators in the electronic press fall over themselves to laud this as the improvement of the decade.

I’m not that good in these matters, but I guessed that if ‘cgroup_enable=memory’ was on already, or even would be missing from the kernel options, I’d find out and roll back.

BTW, I think this is not the way the devs intended us to do. AFAICS now, we need to create configs in /etc/cgconfig.conf and /etc/cgrules.conf, then cgconfig and cgred should be started through the Runlevel Editor, and all the, now manually arranged, commands should be generated from those files. I don’t have the time at the moment to dive in any further right now.

On 2010-11-20 21:06, jdmcdaniel3 wrote:

> So, I am not sure if I will be able to do a lot
> with kernel compiles, but I guaranty I will read the whole thread
> through and through, perhaps even tonight.

The patch is in the HEAD repo, I understand. Read the factory mail list for
more data.


Cheers / Saludos,

Carlos E. R.
(from 11.2 x86_64 “Emerald” at Telcontar)

As I noted in our PM, I applied this to my 32-bit athlon-2800 that is running a 32-bit openSUSE-11.3 with KDE-4.4.4. It has an nVidia GeForce 8400 GS graphic card.

My test was to render a video with KDEnlive (which loads the CPU to 95%) and then while rendering is still taking place, play back a High Definition Video with VDPAU, and surf with firefox.

I saw no performance decrease in firefox (compared to when I would not be rendering and not playing back an HD Video). There typically (without the hack) is a performance drop. Hence that appears to be a performance improvement in that this old 32-bit PC can now run better under heavy load.

Maybe we should make this into a CLEAR guide for openSUSE (using the ubuntu method) and ask others to test ?

Here is what Knurpht and I have applied to our openSUSE-11.3 PCs to test the alternative to the 200 line kernel patch:

With root permissions, add the following lines to the end of /etc/init.d/boot.local

mkdir -p /dev/cgroup/cpu
mount -t cgroup cgroup /dev/cgroup/cpu -o cpu
mkdir -m 0777 /dev/cgroup/cpu/user
echo "/usr/local/sbin/cgroup_clean" > /dev/cgroup/cpu/release_agent

then as a regular user add the following to our ~/.bashrc file :

if  "$PS1" ] ; then  
   mkdir -p -m 0700 /dev/cgroup/cpu/user/$$ > /dev/null 2>&1
   echo $$ > /dev/cgroup/cpu/user/$$/tasks
   echo "1" > /dev/cgroup/cpu/user/$$/notify_on_release
fi

then (with root permissions) created the file /usr/local/sbin/cgroup_clean with this content:

#!/bin/sh
rmdir /dev/cgroup/cpu/$*

and change the permissions on that file with the code:

su -c 'chmod +x /usr/local/sbin/cgroup_clean'

and then when booting, use the boot code:

cgroup_enable=memory

in my case, with root permissions I added “cgroup_enable=memory” to my /boot/grub/menu.lst file after the “splash=silent quiet showopts vga=0x346” in that file’s main boot such that that line ends with “splash=silent quiet showopts vga=0x346 cgroup_enable=memory”. Note I did NOT touch the failsafe section in the /boot/grub/menu.lst.

Then I restarted and tested.

I don’t think this can be applied to an openSUSE-11.2 or earlier PC. It needs to be an openSUSE-11.3 PC. This may not work on an openSUSE-11.4 PC as I think the “cgroup_enable” boot code may have been removed from the 11.4 kernel < not sure > .

EDIT - only those with the kernel-default should be applying this too (I believe < not sure > )

Ubuntu reference (which we copied) is here: Alternative To The "200 Lines Kernel Patch That Does Wonders" Which You Can Use Right Away ~ Web Upd8: Ubuntu / Linux blog

Can we get some more forum testers of this ? (I recommend caution - only those experienced with the sort of edits needed should do this).

If this performance improvement works (its really only visible under heavy load), and if we wish to keep this capability in 11.4, as a group of users we may need to lobby to have an 11.4 kernel change reverted (could be an uphill battle).

Per the edit … I should clarify … I think only experienced users (or adventurous average users like me) who have a kernel-default on their openSUSE-11.3 PC should attempt this. Use at your own risk.

Its working great (thus far) for me, … but there are no guarantees.

I am willing to test it on my test box (3.2GHz Pentium 4, 2GB RAM with 32 bit openSUSE 11.3 and KDE 4.4.4 - Using the default desktop kernel). What specific applications do you want me to test out?

Pick your own applications that you know to load your CPU.

I installed this on my 32-bit AMD Athlon-2800 w/2GB RAM (Asus A7N8X Deluxe motherboard) w/ PCI nVidia GeForce 8400GS graphics [age-5+ years] and a 1920x1200 monitor, where the PC is running a 32-bit openSUSE-11.3 with KDE-4.4.4. To test I rendered a file with KDEnlive (to mpeg2 @ 8MB/sec … which takes about 15 minutes given the file size) and at the same time I played back a high definition video using vdpau (1920x1080 resolution) and I also surfed the Internet with firefox. Typically in this scenario firefox is slow :slight_smile: … but not with the ‘hack’, firefox behavior was nominal as if the other activities were not taking place.

I then installed this on my 32-bit AMD Athlon-1100 w/1GB RAM (MSI KT3 Ultra motherboard) w/AGP nVidia GeForce FX5200 graphics [age 9+ years] with same 1920x1200 monitor, where the PC is running a 32-bit openSUSE-11.3 with LXDE desktop. I noticed a difference simply in surfing with Firefox on a big web page (it draws much quicker now with this hack).

I followed oldcpu’s instructions then rebooted and I can confirm that there seems to be a performance increase in this 5-6 year old machine and it is very responsive :slight_smile:

Opening Firefox and Konsole took about a second to load while without it it took about 6 seconds to load. I will try this on my other testing machine which is a little older (1.7 GHz Celeron, 512MB RAM, 32 bit openSUSE 11.3 GNOME) and I am also willing to test out on my netbook (EEE PC 1000H, 1.6GHz Atom, 1GB RAM, KDE 4.5.3) running 11.4 Milestone 3 if somebody wants to know if it works with 11.4 M3