The kernel patch that does wonders

crocowhile · 2010-11-17 16:17:00

Jurassic wrote:

crocowhile wrote:
aha. no, I am still alive. The kernel is compiled but I didn't have time to start it up and compare yet. A small baby with a stomach bug is incompatible with any form of kernel hacking. Also, the computer I have at home is old; at work I have a i7 and I better try that one anyway.
Sorry to hear abt the baby, but...you're not going to keep us waiting till tomorrow, are you?? Got a PKGBUILD to share?

Just use the one in the archwiki: https://wiki.archlinux.org/index.php/Ke … rom_Source and change the version numbers.
Didn't have time to try it yet but I see few people reported nice results. Cool.

wonder · 2010-11-17 16:19:16

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

praavDa · 2010-11-17 17:08:56

@wonder - thank You very much for the packages.

I will test a bit more, don't want to have any false hopes, but right now I am running 64bit patched kernel on a system with newest packages from testing, under KDE 4.5 and it is either placebo or there really is a difference. Earlier, when I was starting desktop environment, dropbox began to mangle the data and I tried to start almost anything - the "lag" was noticeable. Right now I started kde, then dropbox, eclipse, emacs, dolphin in a 400GB folder with lots & lots of small media files and I was able to smoothly scroll reddit.com in chromium.

Bravo.

Last edited by praavDa (2010-11-17 17:09:46)

Jurassic · 2010-11-17 17:32:15

crocowhile wrote:

Just use the one in the archwiki: https://wiki.archlinux.org/index.php/Ke … rom_Source and change the version numbers.
Didn't have time to try it yet but I see few people reported nice results. Cool.

Thanks, I went the kernel26-bzr route. Just wasn't sure where you got the patch from and to which kernel version you applied it to.

Just curious if anybody who used -ck patches compared them to this one? From my own experience, BFS scheduler didn't change my system responsiveness a slightest bit, prolly difference is more visible on older hardware.

Last edited by Jurassic (2010-11-17 17:33:09)

KlavKalashj · 2010-11-17 17:35:08

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

Thanks for the link! How do I test this? Just install with pacman -U and it's done?

wonder · 2010-11-17 17:51:20

@KlavKalashj and reboot

karabaja4 · 2010-11-17 18:48:52

What exacly does this patch do (besides wonders)? Does it patch up CFS or what (in which case it's incopatible with BFS?).

And why is it "designed to automatically create task groups per TTY in an effort to improve the desktop interactivity"? Does that mean I must run each task in a seperate TTY? What's going on if I would run them from Openbox menu as I usually do?

Last edited by karabaja4 (2010-11-17 18:55:42)

jskier · 2010-11-17 19:16:25

The 2.6.36 patch from the Russian site mentioned earlier works very well, noticeably more responsive. I did the patching myself, not using the packages provided by "wonder".

Anyway, to test aside from running glxgears, browsing, and seeing the general responsiveness improve, do the following to check the kernel:

sysctl -A | grep autogroup

Response should be:

kernel.sched_autogroup_enabled = 1

DonVla · 2010-11-17 19:25:19

karabaja4 wrote:

What exacly does this patch do (besides wonders)? Does it patch up CFS or what (in which case it's incopatible with BFS?).
And why is it "designed to automatically create task groups per TTY in an effort to improve the desktop interactivity"? Does that mean I must run each task in a seperate TTY? What's going on if I would run them from Openbox menu as I usually do?

From the config entry:

+ help
+ This option optimizes the scheduler for common desktop workloads by
+ automatically creating and populating task groups. This separation
+ of workloads isolates aggressive CPU burners (like build jobs) from
+ desktop applications. Task group autogeneration is currently based
+ upon task tty association.

It patches the complete fair scheduler, so you have to use CFS and not BFS, thus the "incompatibility" with BFS.

karabaja4 · 2010-11-17 19:31:12

DonVla wrote:

From the config entry:
/* cut */
It patches the complete fair scheduler, so you have to use CFS and not BFS, thus the "incompatibility" with BFS.

Ok, I kinda assumed that one. But what about my second question? If I were to use improvements that this patch offers, I must run each heavy task in it's own seperate tty? What if I run multiple tasks simultaneously from an Openbox menu or from a file manager?

.

Last edited by karabaja4 (2010-11-17 19:39:13)

GogglesGuy · 2010-11-17 19:39:18

There's actually a nice discussion going on the kernel mailing list. The patch is only usefull if you do tasks that have a tty attached to it. If you only use typical desktop apps, it won't help alot:

http://lkml.indiana.edu/hypermail/linux … 00301.html
http://lkml.indiana.edu/hypermail/linux … 00331.html

slytux · 2010-11-17 19:47:57

Found an interesting article:

http://www.linusakesson.net/programming/tty/index.php

Jurassic · 2010-11-17 19:49:36

Well, then I guess my assumption about scheduler shuffling processes between available tty's (reassigning cgroups) depending on load was wrong?
How does it work in phoronix tests then? I didn't see 'em dropping to another tty to start kbuild. I'm confused

slytux · 2010-11-17 19:57:32

What SCHED_AUTOGROUP does is it automatically configures a rarely used Linux feature (cgroups) to group together related processes so that, under heavy load, certain processes still remain performant under the kernel scheduler.

source: http://innuendopoly.org/arch/sched-autogroup

slytux · 2010-11-17 20:22:07

After reading the mailing lists, it seems that it effects processes that use a terminal. This is serious business if you are compiling stuff.

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

Last edited by slytux (2010-11-17 23:24:09)

karabaja4 · 2010-11-17 20:23:41

Jurassic wrote:

Well, then I guess my assumption about scheduler shuffling processes between available tty's (reassigning cgroups) depending on load was wrong?
How does it work in phoronix tests then? I didn't see 'em dropping to another tty to start kbuild. I'm confused

slytux wrote:

What SCHED_AUTOGROUP does is it automatically configures a rarely used Linux feature (cgroups) to group together related processes so that, under heavy load, certain processes still remain performant under the kernel scheduler.
source: http://innuendopoly.org/arch/sched-autogroup

I guess this post in kernel mailing list should explain it all. It looks like it does infact involve different ttys:

http://lkml.indiana.edu/hypermail/linux … 00428.html

slytux wrote:

After reading, the mailing lists, it seems that it effects processes that use a terminal. This is serious business if you are compiling stuff.
http://lkml.org/lkml/2010/11/16/426

Perhaps. But still, I don't do lot of -jXY compiling myself. They made a huge fuss about this, because most of developers spend alot of time compiling their stuff (including Linus, which was very happy with this patch for that reason). I'll just stick to BFS.

Last edited by karabaja4 (2010-11-17 20:33:28)

Jurassic · 2010-11-17 20:34:54

karabaja4 wrote:

I guess this post in kernel mailing list should explain it all. It looks like it does infact involve different ttys:
http://lkml.indiana.edu/hypermail/linux … 00428.html

No, it doesn't explain how phoronix guys were able to see such a drastic difference w/o starting make -j32 in a separate tty

slytux · 2010-11-17 20:39:15

Linus had some words for Mr. Lennart

http://lkml.indiana.edu/hypermail/linux … 00300.html
http://lkml.indiana.edu/hypermail/linux … 00419.html

slytux · 2010-11-17 20:40:46

Don't forget that your terminal emulator gets allocated a pseudo tty. To find out what the controlling TTY for your shell is called, run ps l or you could simply run the tty command.

Last edited by slytux (2010-11-17 20:43:00)

mangus · 2010-11-17 20:41:44

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

uhuh thanks Wonder , very appreciated!

karabaja4 · 2010-11-17 20:44:54

Jurassic wrote:

No, it doesn't explain how phoronix guys were able to see such a drastic difference w/o starting make -j32 in a separate tty

slytux wrote:

Don't forget that your terminal emulator gets allocated a pseudo tty.

That would mean that phoronix guys ran all these apps on the desktop from different pseudo-ttys, and that pseudo-ttys are affected by this patch just like "real" ttys? *looking at the bunch*

@Linus vs. Lennart on ML: man, those are some harsh words...

.

Last edited by karabaja4 (2010-11-17 20:53:00)

Jurassic · 2010-11-17 20:56:06

Would this also mean that you get to enjoy the patch benefits ONLY if you start applications from separate x-terminals and not from the menu?

thestinger · 2010-11-17 21:01:03

Anything not launched from a virtual terminal or a terminal emulator won't get autogrouped into a cgroup, so this patch ignores normal desktop applications. That just means they get treated as interactive though (and the terminal apps are prevented from slowing them down).

This patch ONLY helps you if you do stuff in the terminal that used to cause desktop lag.

Last edited by thestinger (2010-11-17 21:01:52)

karabaja4 · 2010-11-17 21:01:33

Jurassic wrote:

Would this also mean that you get to enjoy the patch benefits ONLY if you start applications from separate x-terminals and not from the menu?

I guess so, yeah I was saying above, they made too big a fuss about this because this is only important to people that do alot of compiling. Here, I just found a more detailed explanation:

http://lkml.indiana.edu/hypermail/linux … 00424.html

mangus · 2010-11-17 21:01:36

Jurassic wrote:

Would this also mean that you get to enjoy the patch benefits ONLY if you start applications from separate x-terminals and not from the menu?

well , yes...

The only problem is that *desktop* users use *desktop* apps, which
never have a controlling tty.
This is a *nerd* config not helping any regular desktop user. You guys
are optimizing the system for people who build kernels and watch
movies at the same time, not for desktop users. Hooking into TTYs
works for almost nobody sane out there.
It's all fine, no comment on the patch, it's a nice hack. But please
stop talking about the *desktop* here, it has almost nothing to do
with it.

but we're all nerd here, no?

Arch Linux

#26 2010-11-17 16:17:00

Re: The kernel patch that does wonders

#27 2010-11-17 16:19:16

Re: The kernel patch that does wonders

#28 2010-11-17 17:08:56

Re: The kernel patch that does wonders

#29 2010-11-17 17:32:15

Re: The kernel patch that does wonders

#30 2010-11-17 17:35:08

Re: The kernel patch that does wonders

#31 2010-11-17 17:51:20

Re: The kernel patch that does wonders

#32 2010-11-17 18:48:52

Re: The kernel patch that does wonders

#33 2010-11-17 19:16:25

Re: The kernel patch that does wonders

#34 2010-11-17 19:25:19

Re: The kernel patch that does wonders

#35 2010-11-17 19:31:12

Re: The kernel patch that does wonders

#36 2010-11-17 19:39:18

Re: The kernel patch that does wonders

#37 2010-11-17 19:47:57

Re: The kernel patch that does wonders

#38 2010-11-17 19:49:36

Re: The kernel patch that does wonders

#39 2010-11-17 19:57:32

Re: The kernel patch that does wonders

#40 2010-11-17 20:22:07

Re: The kernel patch that does wonders

#41 2010-11-17 20:23:41

Re: The kernel patch that does wonders

#42 2010-11-17 20:34:54

Re: The kernel patch that does wonders

#43 2010-11-17 20:39:15

Re: The kernel patch that does wonders

#44 2010-11-17 20:40:46

Re: The kernel patch that does wonders

#45 2010-11-17 20:41:44

Re: The kernel patch that does wonders

#46 2010-11-17 20:44:54

Re: The kernel patch that does wonders

#47 2010-11-17 20:56:06

Re: The kernel patch that does wonders

#48 2010-11-17 21:01:03

Re: The kernel patch that does wonders

#49 2010-11-17 21:01:33

Re: The kernel patch that does wonders

#50 2010-11-17 21:01:36

Re: The kernel patch that does wonders

Board footer