[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87slce945h.fsf@depni.sinp.msu.ru>
Date: Fri, 09 Mar 2007 12:07:06 +0300
From: Serge Belyshev <belyshev@...ni.sinp.msu.ru>
To: Matt Mackall <mpm@...enic.com>
Cc: Con Kolivas <kernel@...ivas.org>,
linux-kernel <linux-kernel@...r.kernel.org>,
akpm@...ux-foundation.org
Subject: Re: 2.6.21-rc3-mm1 RSDL results
Con Kolivas <kernel@...ivas.org> writes:
> On Friday 09 March 2007 18:53, Matt Mackall wrote:
...
>>
>> With a single non-parallel make running (all in cache, mind you), the
>> system kicks up into just about 100% CPU usage at full speed. Desktop
>> spinning becomes between 10x to 100x slower (from ~30fps to < 1fps).
>> Galeon scrolling pauses for as much as a second. Mouse movement pauses
>> for as much as a second. Typing in terminals lags noticeably.
>>
>> This is not the expected behavior of a fair, low-latency scheduler.
>
> No indeed it does not sound right at all to me either. Last time I encountered
> something like this we traced it and hit sched_yield calls somewhere in the
> graphic pipeline. So first question is, how does mainline perform with the
> same testcase, and second question is umm whatever it is that is slow is
> there a way to trace it to see if it yields?
Matt, some 3d drivers are known to do sched_yield() behind user's back,
(notably dri radeon ones, grep for sched_yield:
http://webcvs.freedesktop.org/mesa/Mesa/src/mesa/drivers/dri/r200/r200_ioctl.c?revision=1.37&view=markup
http://webcvs.freedesktop.org/mesa/Mesa/src/mesa/drivers/dri/r300/radeon_ioctl.c?revision=1.14&view=markup)
thus absolutely killing any desktop interactivity whatsoever.
If you see sched_yield() when stracing any 3d program, I suggest you
to try this bruteforce workaround, which works fine for me,
disable sched_yield():
kernel/sched.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
Index: linux/kernel/sched.c
===================================================================
--- linux.orig/kernel/sched.c
+++ linux/kernel/sched.c
@@ -4285,7 +4285,7 @@ asmlinkage long sys_sched_getaffinity(pi
* This function yields the current CPU by dropping the priority of current
* to the lowest priority.
*/
-asmlinkage long sys_sched_yield(void)
+static long sys_sched_yield1(void)
{
struct rq *rq = this_rq_lock();
struct task_struct *p = current;
@@ -4312,6 +4312,11 @@ asmlinkage long sys_sched_yield(void)
return 0;
}
+asmlinkage long sys_sched_yield(void)
+{
+ return 0;
+}
+
static void __cond_resched(void)
{
#ifdef CONFIG_DEBUG_SPINLOCK_SLEEP
@@ -4395,7 +4400,7 @@ EXPORT_SYMBOL(cond_resched_softirq);
void __sched yield(void)
{
set_current_state(TASK_RUNNING);
- sys_sched_yield();
+ sys_sched_yield1();
}
EXPORT_SYMBOL(yield);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists