It may not work in 11.4 M3, dependant on the kernel …
My research suggests the kernel did not support the “cgroup_enable=memory” in openSUSE-11.2 and earlier. Then as a result of an openFATE submission it was added to openSUSE-11.3 : https://features.opensuse.org/309618 … but then a kernel packager in the community ?? submitted a ‘commit’ to remove it from the openSUSE kernel two months ago: Commit in kernel in openSUSE - Gitorious … hence it may have already been removed from 11.4 Milestone3.
If that is the case, and if there is agreement that this kernel boot code (cgroup_enable) may be beneficial, then I think we will need to
write a new openFATE submission to reverse the kernel commit that has removed “cgroup_enable”, and
join the openSUSE kernel ?? mailing list and bring it to the attention of the kernel packagers that we don’t want the cgroup_enable code removed, and possibly
write a bug report about cgroup_enable code being removed from the kernel and thus we can’t apply this potential performance improvement hack
Of course the above is only a reasonable course of action if (1) my research is correct (and I could be wrong) and (2) if we see a performance improvement when our PCs our under load. … I know I am seeing a slight but noticeable improvement.
You are right - Tried it on 11.4 M3 and there doesn’t seem to be any speed difference. Unfortunatly I can’t seem to access openFATE from here (think my ISP is having problems) but it will be a good idea to submit it to openFATE as well as the mailing list and writing a bug report. I saw on that commit that it said “It is no longer needed” but it looks like we need it again
> If that is the case, and if there is agreement that this kernel boot
> code (cgroup_enable) may be beneficial, then I think we will need to
You need to read the factory mail list, and then notice that the HEAD repo
has a kernel with this feature enabled. Install factory, test that kernel,
report on factory mail list, where the devs that can make the appropriate
changes are.
–
Cheers / Saludos,
Carlos E. R.
(from 11.2 x86_64 “Emerald” at Telcontar)
> I note an old ‘post here’ (http://tinyurl.com/5aoljo), 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.
Use after.local instead
–
Cheers / Saludos,
Carlos E. R.
(from 11.2 x86_64 “Emerald” at Telcontar)
I decided to automate this patch for testing purposes. Further, it runs kwrite to edit your menu.lst file, which will not work for gnome, but I wanted to get this out tonight.
Copy and past the following code as the text file ksp in to your /home bin folder (~/bin/ksp).
#!/bin/bash
#: Title : /home/james/bin/ksp
#: Date Created: Sun Nov 21 16:31:04 CST 2010
#: Last Edit : Sun Nov 21 16:31:04 CST 2010
#: Author : J. McDaniel
#: Version : 1.00
#: Description : Apply Speed Up Patch to openSUSE
#: Options : None
#
#Display One or More Line(s) with different foreground and background colors
# $1=foreground color $2=background color
# $3=Number of Lines to Display
# $4 and higher are lines text to display
# * 0: Black
# * 1: Blue
# * 2: Green
# * 3: Cyan
# * 4: Red
# * 5: Magenta
# * 6: Yellow
# * 7: White
#
function print_color {
fgrd=$1
bgrd=$2
maxnum=$3
counter=1
while $(( counter )) -lt $(( maxnum + 1 )) ] ; do
tput bold
tput setf $(( fgrd ))
tput setb $(( bgrd ))
echo "$4$(tput sgr0)"
let counter=counter+1
shift
done
}
#
# Prompt for user input in bold while, set $CHOICE for use if needed
#
function enter_prompt {
echo
tput bold
tput setf 7
echo -n "$1$(tput sgr0)"
read CHOICE
echo
}
if $UID != 0 ] ; then
if ! -e "/usr/local/sbin/cgroup_clean" ] ; then
tput clear
l1="Kernel Speed-Up Patch Applicator Version 1.00"
l2=""
l3="This will make the following Changes to your openSUSE Configuration"
l4=""
print_color 7 2 4 "$l1" "$l2" "$l3" "$l4"
l1=""
l2="Your ~/.bashrc Text File will have the following Lines Added"
l3=""
print_color 7 1 3 "$l1" "$l2" "$l3"
echo "if \"\$PS1\" ] ; then "
echo " mkdir -p -m 0700 /dev/cgroup/cpu/user/\$\$ > /dev/null 2>&1"
echo " echo \$\$ > /dev/cgroup/cpu/user/\$\$/tasks"
echo " echo \"1\" > /dev/cgroup/cpu/user/\$\$/notify_on_release"
echo "fi"
l1=""
l2="The Script File /usr/local/sbin/cgroup_clean will be created"
l3="to contain the following two lines and marked executable."
l4=""
print_color 7 1 4 "$l1" "$l2" "$l3" "$l4"
echo "#!/bin/sh"
echo "rmdir /dev/cgroup/cpu/\$*"
l1=""
l2="""Your /etc/init.d/boot.local file will be modified, adding the following lines."
l3=""
print_color 7 1 3 "$l1" "$l2" "$l3"
echo "mkdir -p /dev/cgroup/cpu"
echo "mount -t cgroup cgroup /dev/cgroup/cpu -o cpu"
echo "mkdir -m 0777 /dev/cgroup/cpu/user"
echo "echo \"/usr/local/sbin/cgroup_clean\" > /dev/cgroup/cpu/release_agent"
l1=""
l2="And finally, you must modify your Grub menu.lst file and add the following kernel load option."
l3=""
print_color 7 1 3 "$l1" "$l2" "$l3"
echo "----------------> cgroup_enable=memory <----------------------------"
echo
enter_prompt "Are you ready to procedd & make these modifications? (y/N)"
if "$CHOICE" == "y" ] || "$CHOICE" == "Y" ] ; then
echo "if \"\$PS1\" ] ; then " >> ~/.bashrc
echo " mkdir -p -m 0700 /dev/cgroup/cpu/user/\$\$ > /dev/null 2>&1" >> ~/.bashrc
echo " echo \$\$ > /dev/cgroup/cpu/user/\$\$/tasks" >> ~/.bashrc
echo " echo \"1\" > /dev/cgroup/cpu/user/\$\$/notify_on_release" >> ~/.bashrc
echo "fi" >> ~/.bashrc
sudo $0
tput clear
l1="You must add the following Boot option Command to your grub menu.lst"
l2="----------------> cgroup_enable=memory <----------------------------"
l3=""
l4="Would You Like to Edit Your Grub Menu.lst file using the kwrite text editor now?"
l5=""
print_color 7 1 5 "$l1" "$l2" "$l3" "$l4" "$l5"
enter_prompt "Enter your choice [y/N] "
if "$CHOICE" == "y" ] || "$CHOICE" == "Y" ] ; then
echo
/usr/bin/dbus-launch kdesu kwrite /boot/grub/menu.lst
fi
l2=""
l3="Reboot Your Computer to Test the Patch"
l4=""
print_color 7 4 3 "$l1" "$l2" "$l3"
exit 0
fi
else
tput clear
echo "Kernel Speed-Up Patch Applicator Version 1.00"
l1=""
l2=" The file /usr/local/sbin/cgroup_clean already exists. "
l3=" Do not run this patch more than once, please......... "
print_color 7 4 3 "$l1" "$l2" "$l3"
enter_prompt "Press <enter> to exit..."
exit 2
fi
fi
# Do these as Root User
if $UID -eq 0 ] ; then
echo "mkdir -p /dev/cgroup/cpu" >> /etc/init.d/boot.local
echo "mount -t cgroup cgroup /dev/cgroup/cpu -o cpu" >> /etc/init.d/boot.local
echo "mkdir -m 0777 /dev/cgroup/cpu/user" >> /etc/init.d/boot.local
echo "echo \"/usr/local/sbin/cgroup_clean\" > /dev/cgroup/cpu/release_agent" >> /etc/init.d/boot.local
echo "#!/bin/sh" > /usr/local/sbin/cgroup_clean
echo "rmdir /dev/cgroup/cpu/\$*" >> /usr/local/sbin/cgroup_clean
chmod +x /usr/local/sbin/cgroup_clean
fi
exit 0
# End Of Script
To Make the code executable run the terminal command:
chmod +x ~/bin/ksp
To run the patcher, open a terminal session and enter:
ksp
If you try to run the program a second time, it will not run but exit with an error message. This occurs if it finds the file /usr/local/sbin/cgroup_clean already present.
I applied this ‘alternative’ approach to my 64-bit Dell Studio 1537, Intel P8400 w/4GB RAM, w/ATI Radeon 3450HD graphics [age-2 years]. This Dell is running a 64-bit openSUSE-11.3 with KDE-4.4.4.
I have had not much chance to play with the Dell after applying ‘the hack’ (as I need to rush to work). But I did try to play back a high definition (HD) video stored on the drive, where that video is from my Canon HF S10 video camera at 1920x1080 @ 25MB/sec bit rate. I know this laptop can not play back that video (in Linux) as there is no GPU acceleration with the Linux Catalyst driver, and before ‘the hack’ the video tended to play back very jerky, and slow.
With the hack it plays noticeably better, albeit still not as good as in MS-Windows (where the MS-Windows driver can offload the video decode via the GPU). But at “first blush” this does to be an improvement under heavy load.
Did some more testing in the meantime. I must say, I was quite skeptic on this one, but I have to say I’m convinced and impressed.
What I did:
I left the boot option out. Result: watching a HD-video, whilst encoding an MP4 to DVD, brings laggy video, sometimes audio out of sync. Both not the case with the boot option on.
Tried it all on kernel-desktop. Result: no erronious behaviour or whatever, but the effect the hack has on kernel-default is not there.
Took a tour in GoogleEarth. whilst encoding and compiling. It still works !!!
Does this mean you see improved functionality under kernel-default with heavy load, but the same benefit is not there with kernel-desktop under heavy load ?
On 11/22/2010 09:36 AM, oldcpu wrote:
>
> Knurpht;2256256 Wrote:
>> Tried it all on kernel-desktop. Result: no erronious behaviour or
>> whatever, but the effect the hack has on kernel-default is not there.
>> Took a tour in GoogleEarth. whilst encoding and compiling. It still
>> works !!!Does this mean you see improved functionality under kernel-default with
> heavy load, but the same benefit is not there with kernel-desktop under
> heavy load ?
@oldcpu: Could you please put a blank line before your response. It is a bit
difficult to see where your stuff starts. See above.
I applied this ‘alternative’ approach to my 64-bit Dell Studio 1537, Intel P8400 w/4GB RAM, w/ATI Radeon 3450HD graphics [age-2 years]. This Dell is running a 64-bit openSUSE-11.3 with KDE-4.4.4.
I have had not much chance to play with the Dell after applying ‘the hack’ (as I need to rush to work). But I did try to play back a high definition (HD) video stored on the drive, where that video is from my Canon HF S10 video camera at 1920x1080 @ 25MB/sec bit rate. I know this laptop can not play back that video (in Linux) as there is no GPU acceleration with the Linux Catalyst driver, and before ‘the hack’ the video tended to play back very jerky, and slow.
With the hack it plays noticeably better, albeit still not as good as in MS-Windows (where the MS-Windows driver can offload the video decode via the GPU). But at “first blush” this does to be an improvement under heavy load.[/QUOTE]
My last and final install of this ‘hack’, … I applied it on my wife’s PC (which she is soon to give away to our maid), a 32-bit AMD Sempon-2600 w/1GB (Epox EP-8K7A motherboard) w/AGP ATI RV280 (Radeon-9200Pro) graphics [age-4+ years] with a 19" monitor (1280x1024 resolution). It is running a 32-bit openSUSE-11.3 with KDE-4.4.4.
I honestly can’t say after loading I saw any difference. Nothing faster. Nothing slower. I confess since this is my wife’s PC, I am not that familiar with its speed. My load test consisted of installing a bunch of updates from the “update” and “packman” repos, while at the same time also playing a video with smplayer, while at the same time also surfing with firefox. … The desktop struggled a bit with the audio stopping/starting with the video. I had to disable special desktop effects to get a better video/audio playback. … Perhaps that was more a disk access test than a CPU test and I need a better way to check PC performance under load.
On 11/22/2010 02:36 PM, oldcpu wrote:
>
> oldcpu;2256077 Wrote:
>>
>>
>>> oldcpu;2255981 Wrote:
>>> 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 … 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 applied this ‘alternative’ approach to my 64-bit Dell Studio 1537,
>> Intel P8400 w/4GB RAM, w/ATI Radeon 3450HD graphics [age-2 years].
>> This Dell is running a 64-bit openSUSE-11.3 with KDE-4.4.4.
>>
>> I have had not much chance to play with the Dell after applying ‘the
>> hack’ (as I need to rush to work). But I did try to play back a high
>> definition (HD) video stored on the drive, where that video is from my
>> Canon HF S10 video camera at 1920x1080 @ 25MB/sec bit rate. I know
>> this laptop can not play back that video (in Linux) as there is no GPU
>> acceleration with the Linux Catalyst driver, and before ‘the hack’ the
>> video tended to play back very jerky, and slow.
>>
>> With the hack it plays noticeably better, albeit still not as good as
>> in MS-Windows (where the MS-Windows driver can offload the video
>> decode via the GPU). But at “first blush” this does to be an
>> improvement under heavy load.
>
> My last and final install of this ‘hack’, … I applied it on my wife’s
> PC (which she is soon to give away to our maid), a 32-bit AMD
> Sempon-2600 w/1GB (Epox EP-8K7A motherboard) w/AGP ATI RV280
> (Radeon-9200Pro) graphics [age-4+ years] with a 19" monitor (1280x1024
> resolution). It is running a 32-bit openSUSE-11.3 with KDE-4.4.4.
>
> I honestly can’t say after loading I saw any difference. Nothing
> faster. Nothing slower. I confess since this is my wife’s PC, I am not
> that familiar with its speed. My load test consisted of installing a
> bunch of updates from the “update” and “packman” repos, while at the
> same time also playing a video with smplayer, while at the same time
> also surfing with firefox. … The desktop struggled a bit with the
> audio stopping/starting with the video. I had to disable special desktop
> effects to get a better video/audio playback. … Perhaps that was more
> a disk access test than a CPU test and I need a better way to check PC
> performance under load.
Greg KH said on the kernel mailing list that this patch would be the most
important for those people running a lot of command-line stuff, such as building
kernels. Your load is not of that nature.
> I decided to automate this patch for testing purposes. Further, it runs
> kwrite to edit your menu.lst file, which will not work for gnome, but I
> wanted to get this out tonight.
Thanks, Jim. Got just the test case: DB2 operation with multiple scripts
that eat cycles like there was no tomorrow for 1.5+ hours. The load is
pretty well distributed between i/o and disk CPU ops as far as usage time
goes.
The question is how it affects swap usage - that probably eats more cycles
than most of the processes with a combined heavy memory/cpu mix here so
maybe I can at least reduce the wear and tear on the twiddling thumbs…
OK, preliminary results are positive. Screen response is MUCH improved, so
I looked a little closer. Once the disk intensive i/o portion is done
(importing data to initialize the tables) DB2 is able to use cache to good
advantage for most of the rest of the task so things are a bit more visible.
As I said, screen usability is a lot better but there is more.
I’m on an AMD Athlon X2 3600+ with 3 GB of RAM so I’m a tad tight on memory
for real optimization but the original system was keeping BOTH cores jumping
back and forth between 30-35% and 100% usage. With the patch, core 1 is
pretty well saturated continuously while core 2 idles along at about 50%
jumping up basically with desktop activity. Core temps are running 4-5
degrees below what they did without the patch (roughly 53 - 54 degrees C vs
a pretty consistent 60) which is good. Total execution time for the
database task is 100 minutes which is about 5.5 minutes longer than the
original runs. That’s acceptable for personal use but I’d have to think
about it for a real DB server. Of course, I would be browsing the web and
news groups on a real server so the point is irrelevant.
Even dropping a VBox Win XP VM into the mix is much faster. This does force
swap to expand so I’m guessing the core scheduling is also helping that.
I installed the script on a quad cpu machine…but I really want to use it on my celeron 700 laptop with 512mb of memory…the problem is it’s running fedora 13 with lxde…how much would I need to change to make the script non distro specific?
P.S…I would love to run opensuse lxde on the old laptop…when it supports encryption out of the box and suspend to disk with encrypted swap I’ll happily switch to it instead of using the fedora 13 lxde remix which DOES work with all those things out of the box.
per post#24 in this same thread, I noted the approach that Fedora users are taking (which is a bit different for the “alternative for the 200 line patch”) here:
I suspect the Fedora forum could also provide further guidance.
From some of the snippets I’ve read, the “alternative to the 200 line patch” may only be for applications started from a konsole/terminal, as opposed the the 200-line-patch will be more global to all applications, but I don’t know that for certain.
How far does that carry though? if KDM is started from the root console and then apps are kicked off from within the gui wouldn’t they follow the source?
Yes. But maybe I forgot something somewhere. A running video conversion normally eats some reponsiveness from the desktop. With the hack on kernel-default this was much better, even very good, with the hack on kernel-desktop I could not notice any difference opposed to no hack.
