| View previous topic :: View next topic |
| Author |
Message |
RealNC
Tux's lil' helper
Joined: 13 Apr 2008
Posts: 148
|
 Posted: Mon Sep 28, 2009 4:59 am Post subject: Kernel 2.6.30/31 desktop interactivity patch (no BFS) |
 |
|
(Note: If you're not affected by interactivity problems such as those described here:
http://article.gmane.org/gmane.linux.kernel/886413
then you most probably do not need this patch at all.)
Here's a small patch that tweaks the mainline scheduler (CFS) to perform the same way as BFS, at least on the systems I tested on (a Core 2 Duo E6600 and Celeron D 2.4GHz):
http://foss.math.aegean.gr/~realnc/kernel/2.6.31-cfs-tweaks.patch (2009-10-01)
This patch also incorporates some additional tweaks suggested by cheater1034; thanks. (See further down the thread.)
It applies to 2.6.31, but can also be used on 2.6.30 and even older. If it won't apply cleanly on 2.6.30 and older, it should be fairly easy to do those changes by hand.
Applying it is very simple. First test if it applies correctly with:
cd /usr/src/linux-YOUR_VERSION
patch --dry-run -p1 < /path/to/2.6.31-cfs-tweaks.patch
If that checks out OK, apply for real by removing the "--dry-run" option.
Rebuild the kernel and boot it.
The tweaks are minor and should be safe and stable. Most of them are tweaks that can be performed while the kernel is running. However, this requires a debug build of the kernel, and that can result in some runtime overhead; this patch simply changes the default values of those tweakable knobs without the need to build a debug kernel. They have been accepted by Linus for 2.6.32 (Edit: lots of stuff has happened since those changes were submitted by Ingo Molnár; prior to the 2.6.32 merge window closure some major code changes in CFS made it in instead of the minor tweaks of this patch. If you're feeling adventurous, cheater1034 has posted a backport patch further down this thread.)
Last edited by RealNC on Thu Oct 01, 2009 12:53 pm; edited 6 times in total |
|
| Back to top |
|
 |
Naib
Watchman
Joined: 21 May 2004
Posts: 6051
Location: Removed by Neddy
|
| Posted: Mon Sep 28, 2009 11:43 am Post subject: Re: Kernel 2.6.30/31 desktop interactivity patch (no BFS) |
|
|
| RealNC wrote: | Here's a small patch that tweaks the mainline scheduler (CFS) to perform the same way as BFS, at least on the systems I tested on (a Core 2 Duo E6600 and Celeron D 2.4GHz).
The tweaks are minor and safe. They have been accepted by Linus for 2.6.32.
|
is there a link to verify that please?
_________________
| Quote: | | Removed by Chiitoo |
|
|
| Back to top |
|
|
cheater1034
Veteran
Joined: 09 Sep 2004
Posts: 1558
|
| Posted: Mon Sep 28, 2009 6:02 pm Post subject: |
|
|
That patch is kinda lame. I'm not sure why you disabled those things in sched_features?
Apply this over 2.6.31:
http://omploader.org/vMmZ2bQ
It includes: CFS 2.6.32/BFS 240, cfs boost, auto X sched_iso - insignificant if we're testing CFS, right 
Besides JUST 2.6.32 cfs, it does disable LB_BIAS and NEXT_BUDDY - and enable auto X re-nice, and it makes can_migrate_task always return true (even if cache-hot) - this is what I want to test, it may be within ~5% of BFS - It should fix cfs load balancing
It will still be slower for various reasons that I could explain if you were interested, but I'd like to see benchmarks if anyone wants to run some.
it's a massive patch so watch out
_________________
IRC!: #zen-sources on irc.rizon.net
zen-kernel.org
--
Lost in android development land. |
|
| Back to top |
|
|
cheater1034
Veteran
Joined: 09 Sep 2004
Posts: 1558
|
|
| Back to top |
|
|
RealNC
Tux's lil' helper
Joined: 13 Apr 2008
Posts: 148
|
| Posted: Mon Sep 28, 2009 9:58 pm Post subject: |
|
|
This is not a "better" one, this is a backport. I didn't do that one simply because it changes too much stuff. I wanted a stable kernel as opposed to something from a pre-patch rc kernel. So I guess this is for the more "adventurous"
The patch I posted mostly changes stuff that can be changed at runtime if you build a debug kernel. However, building a debug kernel incurs some overhead, that's why I posted the patch with the new changed defaults. |
|
| Back to top |
|
|
cheater1034
Veteran
Joined: 09 Sep 2004
Posts: 1558
|
| Posted: Mon Sep 28, 2009 10:37 pm Post subject: |
|
|
| RealNC wrote: | This is not a "better" one, this is a backport. I didn't do that one simply because it changes too much stuff. I wanted a stable kernel as opposed to something from a pre-patch rc kernel. So I guess this is for the more "adventurous"
The patch I posted mostly changes stuff that can be changed at runtime if you build a debug kernel. However, building a debug kernel incurs some overhead, that's why I posted the patch with the new changed defaults. |
Yes, but I haven't heard anything about those sched_features that you turned off to cause the big performance problems.
As I said I've done things different like turn LB_BIAS off and change the cache-hot migration policy to return true (which should fix cfs load balancing)
An example that was given to me was: x264 encoder runs on 1 cpu, hotness is not better than cpu spread as upstream kernel developers think
Anyway, the backport provides many other tweaks to topology and what not as well, it will still not be as fast as bfs but I'm curious to see just how close it is.
And it disables NEXT_BUDDY as well, http://linux.derkeiler.com/Mailing-Lists/Kernel/2009-09/msg05420.html
_________________
IRC!: #zen-sources on irc.rizon.net
zen-kernel.org
--
Lost in android development land. |
|
| Back to top |
|
|
wrc1944
Advocate
Joined: 15 Aug 2002
Posts: 3435
Location: Gainesville, Florida
|
| Posted: Tue Sep 29, 2009 3:08 am Post subject: |
|
|
I have a 2.6.31 vanilla patched with Con's bfs232, 2.6.31-zen1, and just compiled 2.6.31 with your vMmZ2bQ patch, mentioned above.
Haven't done any benchmarks, but from the little time I've spent with these kernels on my system I think that bfs232 definitely seemed more responsive (subjectively perceived opening windows/apps) than just a plain 2.6.31, and 2.6.31-zen1 seems more responsive than bfs232, and vMmZ2bQ so far seems at least as responsive as zen1.
vMmZ2bQ feels a little "different" somehow- I saw that slub was enabled, and it's the first time I've ever tried that. Don't know if that makes a difference, or not. Seems like an almost inperceptable hesitation opening something, but then when it opens it's instantaneous. With the other kernels, there doesn't seem to be that hesitation, but the overall time required to open something doesn't seem faster. The difference is so infintesimal and subjectively perceived, it's probably my imagination. I guess without running actual benchmarks of some kind my perceptions are not worth too much.
_________________
Main box- AsRock x370 Gaming K4
Ryzen 7 3700x, 3.6GHz, 16GB GSkill Flare DDR4 3200mhz
Samsung SATA 1000GB, Radeon HD R7 350 2GB DDR5
OpenRC Gentoo ~amd64 plasma, glibc-2.36-r7, gcc-13.2.1_p20230304
kernel-6.8.4 USE=experimental python3_11 |
|
| Back to top |
|
|
RealNC
Tux's lil' helper
Joined: 13 Apr 2008
Posts: 148
|
| Posted: Tue Sep 29, 2009 6:55 am Post subject: |
|
|
| cheater1034 wrote: | | RealNC wrote: | This is not a "better" one, this is a backport. I didn't do that one simply because it changes too much stuff. I wanted a stable kernel as opposed to something from a pre-patch rc kernel. So I guess this is for the more "adventurous"
The patch I posted mostly changes stuff that can be changed at runtime if you build a debug kernel. However, building a debug kernel incurs some overhead, that's why I posted the patch with the new changed defaults. |
Yes, but I haven't heard anything about those sched_features that you turned off to cause the big performance problems. |
http://lkml.org/lkml/2009/9/10/229 |
|
| Back to top |
|
|
wrc1944
Advocate
Joined: 15 Aug 2002
Posts: 3435
Location: Gainesville, Florida
|
| Posted: Tue Sep 29, 2009 3:06 pm Post subject: |
|
|
Thought I'd mention that with the 2.6.31 vMmZ2bQ kernel, on shutdown it hangs, after:
| Code: | Terminating reaining processes...
Killing remaining processes...
Saving dependency cache...
Remounting / readonly |
This doesn't happen on the other kernels.
_________________
Main box- AsRock x370 Gaming K4
Ryzen 7 3700x, 3.6GHz, 16GB GSkill Flare DDR4 3200mhz
Samsung SATA 1000GB, Radeon HD R7 350 2GB DDR5
OpenRC Gentoo ~amd64 plasma, glibc-2.36-r7, gcc-13.2.1_p20230304
kernel-6.8.4 USE=experimental python3_11 |
|
| Back to top |
|
|
asturm
Developer
Joined: 05 Apr 2007
Posts: 8935
|
| Posted: Tue Sep 29, 2009 10:06 pm Post subject: |
|
|
| Using your CFS patch, I don't see any advantage... |
|
| Back to top |
|
|
cheater1034
Veteran
Joined: 09 Sep 2004
Posts: 1558
|
| Posted: Wed Sep 30, 2009 12:07 am Post subject: |
|
|
@RealNC
How about this patch?
http://omploader.org/vMmc4MA/2.6.31-cfs-tweaks-2.patch
I'd like to test it up and see how it does  , if you agree on those tweaks maybe you can upload it to your site.
| genstorm wrote: | | Using your CFS patch, I don't see any advantage... |
that's kind of an innaccurate assessment
--------
Here's my latt test (will add the 2.6.31 with only the cfs tweaks later to try)
| Quote: | latt -c8 "make -j2" kernel build
----
Kernel: 2.6.31-zen2-bfs-3337ea3
Parameters: min_wait=100ms, max_wait=500ms, clients=8
Entries logged: 5712
Wakeup averages
-------------------------------------
Max 38796 usec
Avg 11284 usec
Stdev 9259 usec
Stdev mean 123 usec
Work averages
-------------------------------------
Max 143410 usec
Avg 101290 usec
Stdev 17148 usec
Stdev mean 227 usec
Kernel: 2.6.31-zen2-cfs-3337ea3
Parameters: min_wait=100ms, max_wait=500ms, clients=8
Entries logged: 5880
Wakeup averages
-------------------------------------
Max 34962 usec
Avg 4532 usec
Stdev 3801 usec
Stdev mean 50 usec
Work averages
-------------------------------------
Max 202057 usec
Avg 119865 usec
Stdev 16360 usec
Stdev mean 213 usec
Kernel: 2.6.31-bfs240
Parameters: min_wait=100ms, max_wait=500ms, clients=8
Entries logged: 5448
Wakeup averages
-------------------------------------
Max 40659 usec
Avg 11512 usec
Stdev 9372 usec
Stdev mean 127 usec
Work averages
-------------------------------------
Max 152649 usec
Avg 100517 usec
Stdev 17549 usec
Stdev mean 238 usec
Kernel: 2.6.31.1
Parameters: min_wait=100ms, max_wait=500ms, clients=8
Entries logged: 6744
Wakeup averages
-------------------------------------
Max 54973 usec
Avg 13978 usec
Stdev 10848 usec
Stdev mean 132 usec
Work averages
-------------------------------------
Max 155076 usec
Avg 87660 usec
Stdev 19173 usec
Stdev mean 233 usec |
The correlation is somewhat clear on this test:
* cfs at that commit in zen has much lower latencies than 2.6.31
* bfs has lower wakeup latencies than 2.6.31, but work latencies are closer
* zen2-bfs has lower work latencies than zen2-cfs - cfs = lower wakeup latencies
Basically, huge improvement with zen2-cfs versus 2.6.31 vanilla cfs - zen2-bfs has improvement over 2.6.31-bfs240, zen2-bfs still has lower latencies than zen2-cfs (but it's a MAJOR improvement for cfs)
Anyway, interpret the results :O
kinda strange to see the 2.6.31-bfs versus 2.6.31, and the zen2-bfs versus 2.6.31-bfs (the only thing that really changed is 2.6.32 backports for bfs)
_________________
IRC!: #zen-sources on irc.rizon.net
zen-kernel.org
--
Lost in android development land. |
|
| Back to top |
|
|
tranquilcool
Veteran
Joined: 25 Mar 2005
Posts: 1179
|
| Posted: Wed Sep 30, 2009 9:22 am Post subject: |
|
|
what's latest stable version of zen-sources at the moment?
is bfs-240 applied?
thanks.
_________________
this is a strange strange world. |
|
| Back to top |
|
|
RealNC
Tux's lil' helper
Joined: 13 Apr 2008
Posts: 148
|
| Posted: Thu Oct 01, 2009 7:00 am Post subject: |
|
|
Thanks. Though I didn't notice any improvements, on LKML people theorized they should improve things in some cases.
Note:
| Code: | diff --git a/kernel/sched.c b/kernel/sched.c
index 1b59e26..138553d 100644
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -3233,7 +3233,7 @@ int can_migrate_task(struct task_struct *p, struct rq *rq, int this_cpu,
if (tsk_cache_hot) {
schedstat_inc(p, se.nr_failed_migrations_hot);
- return 0;
+ return 1;
}
return 1;
}
|
Where did you pick that one from? Btw, eliminating the if alltogether would be more correct, since now a comparison is executed that serves no purpose. In other words:
| Code: | diff --git a/kernel/sched.c b/kernel/sched.c
index 1b59e26..138553d 100644
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -3230,11 +3230,6 @@
#endif
return 1;
}
-
- if (tsk_cache_hot) {
- schedstat_inc(p, se.nr_failed_migrations_hot);
- return 0;
- }
return 1;
}
|
|
|
| Back to top |
|
|
RealNC
Tux's lil' helper
Joined: 13 Apr 2008
Posts: 148
|
| Posted: Thu Oct 01, 2009 7:36 am Post subject: |
|
|
| wrc1944 wrote: | | I saw that slub was enabled |
SLUB is the default actually. Not sure when that happened, but it's been a while now. SLAB is still in the kernel, but disabled by default. |
|
| Back to top |
|
|
RealNC
Tux's lil' helper
Joined: 13 Apr 2008
Posts: 148
|
| Posted: Thu Oct 01, 2009 7:53 am Post subject: |
|
|
| I updated the patch and my first post. |
|
| Back to top |
|
|
asturm
Developer
Joined: 05 Apr 2007
Posts: 8935
|
| Posted: Thu Oct 01, 2009 5:47 pm Post subject: |
|
|
| cheater1034 wrote: | | genstorm wrote: | | Using your CFS patch, I don't see any advantage... |
that's kind of an innaccurate assessment |
Quite true actually. I didn't benchmark anything, just noticed my desktop performance got down on its knees even more than usually while compiling stuff.
I think it's time to try out zen-sources again.  |
|
| Back to top |
|
|
cheater1034
Veteran
Joined: 09 Sep 2004
Posts: 1558
|
| Posted: Fri Oct 02, 2009 12:40 am Post subject: |
|
|
RealNC:
That change is from deliberation in #zen-sources, possible influence from #ck
My original patch deleted the whole comparison, but AStorm said not to for some reason so i didn't 
*edit*
BFS is fixed in zen-stable, basically got rid of all 2.6.32 sched stuff, since.... well, now we have 2.6.32 (and 2.6.32-zen), and it will fix bfs too
_________________
IRC!: #zen-sources on irc.rizon.net
zen-kernel.org
--
Lost in android development land. |
|
| Back to top |
|
|
|
Unsupported Software
