From: Ingo Molnar <mingo@elte.hu>
To: Kasper Sandberg <lkml@metanurb.dk>
Cc: Mike Galbraith <efault@gmx.de>,
linux-kernel@vger.kernel.org,
Linus Torvalds <torvalds@linux-foundation.org>,
Andrew Morton <akpm@linux-foundation.org>,
Con Kolivas <kernel@kolivas.org>, Nick Piggin <npiggin@suse.de>,
Arjan van de Ven <arjan@infradead.org>,
Peter Williams <pwil3058@bigpond.net.au>,
Thomas Gleixner <tglx@linutronix.de>,
caglar@pardus.org.tr, Willy Tarreau <w@1wt.eu>,
Gene Heskett <gene.heskett@gmail.com>, Mark Lord <lkml@rtr.ca>
Subject: Re: [patch] CFS scheduler, -v11
Date: Fri, 11 May 2007 13:07:54 +0200 [thread overview]
Message-ID: <20070511110754.GA13985@elte.hu> (raw)
In-Reply-To: <1178725597.10077.1.camel@localhost>
[ remailing this on-list too, with some more explanations, i suspect
others might be affected by this 3D performance problem as well. ]
* Kasper Sandberg <lkml@metanurb.dk> wrote:
> [...] but under harder load such as pressing a link in a browser while
> 3d(at nice 0), or spamasassin at nice 0 still makes it go stutterish
> instead of smooth. But overall it does seem better.
ok, i think i have finally managed to track this one down.
certain 3D drivers grew a subtle performance dependency on a
sys_sched_yield() implementation/behavioral bug/misbehavior of the
upstream kernel, which implementation SD does too, but CFS fixes it by
always yielding efficiently. The result of this bug/dependency is
extremely low FPS during any CPU-intense workload.
you are using an Nvidia 6600 card so i dont know for sure whether you
are affected by this problem (Radeon cards are affected and i can now
reproduce that) - but the symptoms i've reproduced seem to be matching
your system's symptoms.
I've added a workaround for this to CFS, do you have some time to try
it? I've attached the sched-cfs-v12-rc4.patch (delta patch ontop of a
CFS -v11 tree), and once you have booted it you can activate the
workaround via:
echo 1 > /proc/sys/kernel/sched_yield_bug_workaround
does this make any difference to the drastic 3D smoothness problems you
are experiencing?
Ingo
---
Makefile | 2 +-
drivers/char/drm/radeon_cp.c | 5 +++++
include/linux/sched.h | 2 +-
kernel/sched_fair.c | 23 +++++++++++++++++++----
kernel/sysctl.c | 12 ++++++------
5 files changed, 32 insertions(+), 12 deletions(-)
Index: linux/Makefile
===================================================================
--- linux.orig/Makefile
+++ linux/Makefile
@@ -1,7 +1,7 @@
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 21
-EXTRAVERSION = -cfs-v11
+EXTRAVERSION = -cfs-v12
NAME = Nocturnal Monster Puppy
# *DOCUMENTATION*
Index: linux/drivers/char/drm/radeon_cp.c
===================================================================
--- linux.orig/drivers/char/drm/radeon_cp.c
+++ linux/drivers/char/drm/radeon_cp.c
@@ -2210,6 +2210,11 @@ int radeon_driver_load(struct drm_device
DRM_DEBUG("%s card detected\n",
((dev_priv->flags & RADEON_IS_AGP) ? "AGP" : (((dev_priv->flags & RADEON_IS_PCIE) ? "PCIE" : "PCI"))));
+ if (sysctl_sched_yield_bug_workaround == -1) {
+ sysctl_sched_yield_bug_workaround = 1;
+ printk(KERN_WARNING "quirk installed: turning on "
+ "sys_sched_yield() workaround for Radeon DRM.\n");
+ }
return ret;
}
Index: linux/include/linux/sched.h
===================================================================
--- linux.orig/include/linux/sched.h
+++ linux/include/linux/sched.h
@@ -1253,9 +1253,9 @@ extern char * sched_print_task_state(str
extern unsigned int sysctl_sched_granularity;
extern unsigned int sysctl_sched_wakeup_granularity;
-extern unsigned int sysctl_sched_sleep_history_max;
extern unsigned int sysctl_sched_child_runs_first;
extern unsigned int sysctl_sched_load_smoothing;
+extern int sysctl_sched_yield_bug_workaround;
#ifdef CONFIG_RT_MUTEXES
extern int rt_mutex_getprio(struct task_struct *p);
Index: linux/kernel/sched_fair.c
===================================================================
--- linux.orig/kernel/sched_fair.c
+++ linux/kernel/sched_fair.c
@@ -18,10 +18,6 @@
*/
unsigned int sysctl_sched_granularity __read_mostly = 2000000;
-unsigned int sysctl_sched_sleep_history_max __read_mostly = 2000000000;
-
-unsigned int sysctl_sched_load_smoothing = 0 | 0 | 0 | 8;
-
/*
* Wake-up granularity.
* (default: 1 msec, units: nanoseconds)
@@ -32,6 +28,19 @@ unsigned int sysctl_sched_load_smoothing
*/
unsigned int sysctl_sched_wakeup_granularity __read_mostly = 0;
+unsigned int sysctl_sched_load_smoothing __read_mostly = 0 | 0 | 0 | 8;
+
+/*
+ * sys_sched_yield unfairness bug workaround switch.
+ * (default: -1:auto-detect+disabled. Other values: 0:disabled, 1:enabled)
+ *
+ * This option switches the unfair yield implementation of the
+ * old scheduler back on. Needed for good performance of certain
+ * apps like 3D games on Radeon cards.
+ */
+int sysctl_sched_yield_bug_workaround __read_mostly = -1;
+
+EXPORT_SYMBOL_GPL(sysctl_sched_yield_bug_workaround);
extern struct sched_class fair_sched_class;
@@ -462,6 +471,12 @@ yield_task_fair(struct rq *rq, struct ta
u64 now;
/*
+ * Bug workaround for 3D apps running on the radeon 3D driver:
+ */
+ if (unlikely(sysctl_sched_yield_bug_workaround > 0))
+ return;
+
+ /*
* yield-to support: if we are on the same runqueue then
* give half of our wait_runtime (if it's positive) to the other task:
*/
Index: linux/kernel/sysctl.c
===================================================================
--- linux.orig/kernel/sysctl.c
+++ linux/kernel/sysctl.c
@@ -223,24 +223,24 @@ static ctl_table kern_table[] = {
},
{
.ctl_name = CTL_UNNUMBERED,
- .procname = "sched_sleep_history_max_ns",
- .data = &sysctl_sched_sleep_history_max,
+ .procname = "sched_child_runs_first",
+ .data = &sysctl_sched_child_runs_first,
.maxlen = sizeof(unsigned int),
.mode = 0644,
.proc_handler = &proc_dointvec,
},
{
.ctl_name = CTL_UNNUMBERED,
- .procname = "sched_child_runs_first",
- .data = &sysctl_sched_child_runs_first,
+ .procname = "sched_load_smoothing",
+ .data = &sysctl_sched_load_smoothing,
.maxlen = sizeof(unsigned int),
.mode = 0644,
.proc_handler = &proc_dointvec,
},
{
.ctl_name = CTL_UNNUMBERED,
- .procname = "sched_load_smoothing",
- .data = &sysctl_sched_load_smoothing,
+ .procname = "sched_yield_bug_workaround",
+ .data = &sysctl_sched_yield_bug_workaround,
.maxlen = sizeof(unsigned int),
.mode = 0644,
.proc_handler = &proc_dointvec,
next prev parent reply other threads:[~2007-05-11 11:09 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-08 15:04 [patch] CFS scheduler, -v11 Ingo Molnar
2007-05-09 15:46 ` Kasper Sandberg
2007-05-11 11:07 ` Ingo Molnar [this message]
2007-05-09 18:02 ` Definition of fairness (was Re: [patch] CFS scheduler, -v11) Srivatsa Vaddagiri
2007-05-09 19:24 ` Dmitry Adamushko
2007-05-10 16:41 ` Srivatsa Vaddagiri
2007-05-09 20:24 ` William Lee Irwin III
2007-05-10 17:13 ` Srivatsa Vaddagiri
2007-05-10 18:55 ` William Lee Irwin III
2007-05-10 4:22 ` David Schwartz
2007-05-10 8:51 ` Mike Galbraith
2007-05-10 20:02 ` Ingo Molnar
2007-05-10 19:54 ` Ting Yang
2007-05-10 16:59 ` [patch] CFS scheduler, -v11 Christian
2007-05-10 17:10 ` Kasper Sandberg
2007-05-10 18:51 ` Christian
2007-05-10 19:45 ` Ingo Molnar
2007-05-10 20:05 ` Ingo Molnar
2007-05-11 12:01 ` Christian
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070511110754.GA13985@elte.hu \
--to=mingo@elte.hu \
--cc=akpm@linux-foundation.org \
--cc=arjan@infradead.org \
--cc=caglar@pardus.org.tr \
--cc=efault@gmx.de \
--cc=gene.heskett@gmail.com \
--cc=kernel@kolivas.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lkml@metanurb.dk \
--cc=lkml@rtr.ca \
--cc=npiggin@suse.de \
--cc=pwil3058@bigpond.net.au \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=w@1wt.eu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.