[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1252552527.6342.18.camel@marge.simson.net>
Date: Thu, 10 Sep 2009 05:15:27 +0200
From: Mike Galbraith <efault@....de>
To: Nikos Chantziaras <realnc@...or.de>
Cc: Ingo Molnar <mingo@...e.hu>, Jens Axboe <jens.axboe@...cle.com>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Con Kolivas <kernel@...ivas.org>, linux-kernel@...r.kernel.org
Subject: Re: BFS vs. mainline scheduler benchmarks and measurements
On Wed, 2009-09-09 at 23:12 +0300, Nikos Chantziaras wrote:
> With your version of latt.c, I get these results with 2.6-tip vs
> 2.6.31-rc9-bfs:
>
>
> (mainline)
> Averages:
> ------------------------------
> Max 50 usec
> Avg 12 usec
> Stdev 3 usec
>
>
> (BFS)
> Averages:
> ------------------------------
> Max 474 usec
> Avg 11 usec
> Stdev 16 usec
>
>
> However, the interactivity problems still remain. Does that mean it's
> not a latency issue?
Could be a fairness issue. If X+client needs more than it's fair share
of CPU, there's nothing to do but use nice levels. I'm stuck with
unaccelerated X (nvidia card), so if I want a good DVD watching or
whatever eye-candy experience while my box does a lot of other work, I
either have to use SCHED_IDLE/nice for the background stuff, or renice
X. That's the down side of a fair scheduler.
There is another variant of latency related interactivity issue for the
desktop though, too LOW latency. If X and clients are switching too
fast, redraw can look nasty, sliced/diced.
-Mike
--
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