The kernel patch that does wonders

Jurassic · 2010-11-18 01:44:42

karabaja4 wrote:

If this is true, this patch would make more harm than good for "normal" desktop users. However, I can't imagien why this would be true - I mean, this patch shouldn't affect processes running in the same tty.

Well, that's exactly what Con Kolivas said in his blog. And I kinda tend to believe him...

EDIT
Another interesting piece of information: http://lkml.org/lkml/2010/11/16/413
Apparently no kernel patch required to achieve the same effect, cgroups api is all that's needed. So we can all start grouping threads/processes at will, yay!
Seriously though, I think what CK says about using schedtool/nice is a better and cleaner way with no hackery involved. I should really start using it more often...

Last edited by Jurassic (2010-11-18 01:53:02)

karabaja4 · 2010-11-18 01:59:06

Jurassic wrote:

Well, that's exactly what Con Kolivas said in his blog. And I kinda tend to believe him...

Yeah, I know, I went through whole process of getting my facts straight. Just ignore my older posts

kinghajj · 2010-11-18 02:08:51

wonder wrote:

packages are here http://pkgbuild.com/~ioni/
i didn't bump pkgrel at all so keep that in mind when the next kernel upgrade occurs in the repo

I'm having trouble getting nvidia-all and ndiswrapper-all to work with this kernel. I built it myself, installed, and rebooted. ndiswrapper-all always fails to compile, whereas the nvidia module fails to load because "no device found." Has anyone gotten these to work with the patched 2.6.36 kernel here?

Last edited by kinghajj (2010-11-18 02:09:02)

slytux · 2010-11-18 05:53:48

I couldn't get my nvidia module working with 2.6.37-rc2 so I used zen-kernel's stable 2.6.36 sources--and just browsing with firefox, the patch is tremendous!

Last edited by slytux (2010-11-18 05:54:55)

slytux · 2010-11-18 06:10:50

Try using the abs to build the nvidia module instead. You have to edit the nvidia.install file to have the proper version+name for KERNEL_VERSION (twice). And in the PKGBUILD: change the pkgname from nvidia to something else like nvidia-rc (so it won't override Arch's nvidia) and the _kernver variable should match what you're building for. Also, since this is 2.6.36 and the stock arch kernel is at 2.6.35, just bump the versions on the depends/makedepends line.

Last edited by slytux (2010-11-18 06:27:13)

Fruity · 2010-11-18 06:12:30

@ combuster, that good hey? Well just shiney! Will give it a whirl.

rwd · 2010-11-18 21:15:06

I now log in with mingetty set in innittab, and then start x from the commandline. Do I have to change to using a displaymanager to benefit from this patch?

It would be great if someone could make an aur package for this, including one for the nvidia/nvidia beta driver.

Last edited by rwd (2010-11-18 21:31:26)

thestinger · 2010-11-18 21:33:02

rwd wrote:

I now log in with mingetty set in innittab, and then start x from the commandline. Do I have to change to using a loginmanager to benefit from this patch?
It would be great if someone could make an aur package for this, including one for the nvidia/nvidia beta driver.

It won't work as intended if you startx from a tty, in fact, it will probably make things worse in some cases (because it will treat all your desktop apps with lower priority since they are under the SAME tty). It will still stop a terminal running a compile with a lot of jobs from interfering with your other programs though.

That doesn't mean you need a display manager, just use something like this in inittab

x:5:once:/bin/su thestinger -l -c "/usr/bin/startx >/dev/null 2>&1"

or avoid startx (which is a shell script wrapper and adds some startup time):

x:5:once:/bin/su thestinger -l -c "/usr/bin/xinit ~/.config/xinitrc -- /usr/bin/X -nolisten tcp vt04 >/dev/null 2>&1"

You can start in init 3, and do init 5 to start X. Or, set runlevel 5 to default to have it start on boot.

Last edited by thestinger (2010-11-18 21:34:56)

gbj13 · 2010-11-19 07:59:29

Has anyone looked at this alternative to the kernel patch?
http://www.webupd8.org/2010/11/alternat … patch.html

Last edited by gbj13 (2010-11-19 08:01:27)

dudell · 2010-11-19 08:44:22

rwd wrote:

I now log in with mingetty set in innittab, and then start x from the commandline. Do I have to change to using a displaymanager to benefit from this patch?
It would be great if someone could make an aur package for this, including one for the nvidia/nvidia beta driver.

Instead to use the patch you can use the alternative way. If you do not create a cgroup for tty1, then all process started not from a terminal get the same time as different groups (like make -j64 started from a terminal)

ga01f4733 · 2010-11-19 09:25:42

@gbj13

I'm using the alternative, in an atom netbook, no problems at all.

http://www.webupd8.org/2010/11/alternat … patch.html
http://linux.slashdot.org/story/10/11/1 … rnel-Patch

handy · 2010-11-19 10:49:06

I did the following to run the this cgroup stuff, courtesy of Vivek Goyal's post here:

http://lkml.org/lkml/2010/11/16/413

It is working, but I haven't been using it long enough to really notice any difference at this stage...

eldragon · 2010-11-19 15:45:12

graysky wrote:

http://ck-hack.blogspot.com/2010/11/cre … mment.html
Con Kolivas wrote:
I've had every man and his dog either drop into IRC or email me asking me what my thoughts are on the grouping tasks by tty layer patch discussed here: Phoronix link and slashdot. I guess people didn't understand my 2.6.36-ck1 announcement clearly enough, so I'll quote it again here:
Those following the development of the patches for interactivity at massive
load, I have COMPLETELY DROPPED them as they introduce regressions at normal
workloads, and I cannot under any circumstances approve changes to improve
behaviour at ridiculous workloads which affect regular ones. I still see
precisely zero point at optimising for absurd workloads. Proving how many
un-niced jobs you can throw at your kernel compiles is not a measure of one's
prowess. It is just a mindless test.

Remember, I already had developed a hierarchical tree-based penalty patch for BFS and blogged about it here. I can do it in a 10 line patch for BFS, but it introduced regressions, which is why I dropped it (see earlier blog entry here: further-updates-on-hierarchical-tree).
Again, I can't for the life of me see why you'd optimise for make -j64 on a quad core machine. It is one workload, unique to people who compile all the time, but done in a way you wouldn't normally do it anyway. It is not going to magically make anything else better. If for some god-forsaken reason you wanted to do that, you could already do that with nice, or even better, by running it SCHED_IDLEPRIO.
nice -19 make -j 64 blahblah
or
schedtool -D -e make -j64 blahblah
It's not really that hard folks...
And if you really really really still want the feature for BFS, the patch that does the hierarchical tree based penalty is rolled into a bigger patch (so a lot more than just the 10 lines I mentioned) that can also group threads and enable/disable the features and it's still here:
bfs357-penalise_fork_depth_account_threads.patch
It is worth noting also that the mainline approach costs you in throughput, whereas this patch is virtually free.
EDIT: I forgot to mention that for YEARS now I've been using my "toolsched" wrapper scripts that do this automatically. See toolsched for the scripts. Make always starts as SCHED_IDLEPRIO for me at home.

hmm, con kolivas is usually quite biased on his opinions. i already knew he was going to dismiss the whole thing even before reading his blog.
better test all alternatives and see whats better. ive already dropped BFS since i wasnt noticing any extra snappyness on my system. i will definately test this new approach once it matures a bit.

Jacek Poplawski · 2010-11-19 19:38:01

http://www.webupd8.org/2010/11/alternat … patch.html

tomk · 2010-11-19 19:43:11

Jacek, gbj13 posted that link already. Please read the thread before posting.

Octoploid · 2010-11-19 20:03:15

Here's what I use right now.

.bashrc or .zshrc

if [ "$PS1" ] ; then                                                                                                                               
    mkdir -m 0700 /cgroup/$$
    echo $$ > /cgroup/$$/tasks
    echo 1 > /cgroup/$$/notify_on_release
fi

/etc/rc.local

mount -t cgroup cgroup /cgroup -o cpu
chmod 0777 /cgroup
echo "/sbin/rm_cgroup" > /cgroup/release_agent

/sbin/rm_cgroup

#!/bin/sh
rmdir /cgroup/$1

Then just chmod +x /sbin/rm_cgroup
and "mkdir /cgroup" as root.
Reboot and you're set...

Basn · 2010-11-19 20:10:33

handy wrote:

I did the following to run the this cgroup stuff, courtesy of Vivek Goyal's post here:
http://lkml.org/lkml/2010/11/16/413
It is working, but I haven't been using it long enough to really notice any difference at this stage...

Uhm, i think i got it working looking at that, but how does it work do you have to have it for each terminal etc? i dont really get it

rwd · 2010-11-19 20:40:13

I configured the method described at http://www.webupd8.org/2010/11/alternat … patch.html. Is there a way to verify that it works? Also is this also useful with just a few gui applications open, or only when combined with terminals that spawn lots of cpu intensive processes?

Last edited by rwd (2010-11-19 21:07:56)

thestinger · 2010-11-19 21:20:40

all it does is stop a really intensive task (many processes/threads) in a terminal from hogging all the cpu cycles, read the links posted in this thread

Fruity · 2010-11-20 03:56:15

Does anyone know if or when this will be pushed into a kernel release (automated per tty task groups patch). Will it be in 2.6.37?

I'm also curious to know: Lets say 2.6.37 has this patch added, what would happen if I then tried to build a custom kernel with 2.6.37 and included this patch again in the build. Would it do nothing, cause harm, etc?

Allan · 2010-11-20 03:59:22

Fruity wrote:

I'm also curious to know: Lets say 2.6.37 has this patch added, what would happen if I then tried to build a custom kernel with 2.6.37 and included this patch again in the build. Would it do nothing, cause harm, etc?

the patch command would likely fail, and makepkg would bail.

karol · 2010-11-20 04:07:08

Fruity wrote:

I'm also curious to know: Lets say 2.6.37 has this patch added, what would happen if I then tried to build a custom kernel with 2.6.37 and included this patch again in the build. Would it do nothing, cause harm, etc?

I suggest you learn what patching means, what that command does and only then try to have some fun with the kernel or other apps.

Last edited by karol (2010-11-20 04:08:00)

Fruity · 2010-11-20 04:19:07

karol wrote:

I suggest you learn what patching means, what that command does and only then try to have some fun with the kernel or other apps.

Odd, I learnt something from Allans answer. Its what forums are for, no? Ask a question relevant to a thread, get a reply of use. Yes? I've always found elitist remarks about go learn elsewhere, kind of sad It's what forums are for, to spread knowledge and ask for answers on topics you dont know.

If I knew more, I wouldnt of asked. I'll strive for omniscience just for you karol.

bangkok_manouel · 2010-11-20 04:21:12

Fruity wrote:

Does anyone know if or when this will be pushed into a kernel release (automated per tty task groups patch). Will it be in 2.6.37?

No, it came too late, merge window for .37 was closed.

Fruity wrote:

I'm also curious to know: Lets say 2.6.37 has this patch added, what would happen if I then tried to build a custom kernel with 2.6.37 and included this patch again in the build. Would it do nothing, cause harm, etc?

eb@blackout:~$ patch -Np0 < test.patch 
patching file a
eb@blackout:~$ patch -Np0 < test.patch 
patching file a
Reversed (or previously applied) patch detected!  Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file a.rej

karol · 2010-11-20 04:22:17

Fruity wrote:

karol wrote:
I suggest you learn what patching means, what that command does and only then try to have some fun with the kernel or other apps.
Odd, I learnt something from Allans answer. Its what forums are for, no? Ask a question relevant to a thread, get a reply of use. Yes? I've always found elitist remarks about go learn elsewhere, kind of sad It's what forums are for, to spread knowledge and ask for answers on topics you dont know.
If I knew more, I wouldnt of asked. I'll strive for omniscience just for you karol.

How about reading the man page first? It's not black magic, you know. You don't need to "go elsewhere", just type 'man patch'.

Arch Linux

#76 2010-11-18 01:44:42

Re: The kernel patch that does wonders

#77 2010-11-18 01:59:06

Re: The kernel patch that does wonders

#78 2010-11-18 02:08:51

Re: The kernel patch that does wonders

#79 2010-11-18 05:53:48

Re: The kernel patch that does wonders

#80 2010-11-18 06:10:50

Re: The kernel patch that does wonders

#81 2010-11-18 06:12:30

Re: The kernel patch that does wonders

#82 2010-11-18 21:15:06

Re: The kernel patch that does wonders

#83 2010-11-18 21:33:02

Re: The kernel patch that does wonders

#84 2010-11-19 07:59:29

Re: The kernel patch that does wonders

#85 2010-11-19 08:44:22

Re: The kernel patch that does wonders

#86 2010-11-19 09:25:42

Re: The kernel patch that does wonders

#87 2010-11-19 10:49:06

Re: The kernel patch that does wonders

#88 2010-11-19 15:45:12

Re: The kernel patch that does wonders

#89 2010-11-19 19:38:01

Re: The kernel patch that does wonders

#90 2010-11-19 19:43:11

Re: The kernel patch that does wonders

#91 2010-11-19 20:03:15

Re: The kernel patch that does wonders

#92 2010-11-19 20:10:33

Re: The kernel patch that does wonders

#93 2010-11-19 20:40:13

Re: The kernel patch that does wonders

#94 2010-11-19 21:20:40

Re: The kernel patch that does wonders

#95 2010-11-20 03:56:15

Re: The kernel patch that does wonders

#96 2010-11-20 03:59:22

Re: The kernel patch that does wonders

#97 2010-11-20 04:07:08

Re: The kernel patch that does wonders

#98 2010-11-20 04:19:07

Re: The kernel patch that does wonders

#99 2010-11-20 04:21:12

Re: The kernel patch that does wonders

#100 2010-11-20 04:22:17

Re: The kernel patch that does wonders

Board footer