From: Mike Galbraith <efault@gmx.de>
To: Con Kolivas <kernel@kolivas.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: BFS v0.311 CPU scheduler for 2.6.32
Date: Fri, 11 Dec 2009 11:29:30 +0100 [thread overview]
Message-ID: <1260527370.6126.53.camel@marge.simson.net> (raw)
In-Reply-To: <200912111124.18118.kernel@kolivas.org>
On Fri, 2009-12-11 at 11:24 +1100, Con Kolivas wrote:
> When choosing an idle CPU for a waking task, the cache locality is determined
> according to where the task last ran and then idle CPUs are ranked from best
> to worst to choose the most suitable idle CPU based on cache locality, NUMA
> node locality and hyperthread sibling business.
The affinity logic still seems to want some loving. Everything I've
tested that is cache sensitive suffers pretty heavily.
FWIW, mysql+oltp is a nice repeatable affinity testcase. tbench is
another. Throughput for both under BFS 311 here are still consistent
with the cost of pairs landing cross-cache on a regular basis. I'm no
fan of vmark, but it's also highly cache sensitive, and is sensitive to
overly enthusiastic wakeup preemption as well, so is useful to keep an
eye on both (otherwise, 800 threads on 4 cores is silly imho). Vmark
does not enjoy the BFS experience (understatement squared).
-Mike
next prev parent reply other threads:[~2009-12-11 10:29 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-11 0:24 Con Kolivas
2009-12-11 10:29 ` Mike Galbraith [this message]
2009-12-11 14:10 ` Christoph Lameter
2009-12-11 15:04 ` Con Kolivas
2009-12-11 15:12 ` Christoph Lameter
2009-12-11 22:37 ` Con Kolivas
2009-12-12 0:55 ` Bartlomiej Zolnierkiewicz
2009-12-12 2:00 ` Con Kolivas
2009-12-12 3:22 ` Bartlomiej Zolnierkiewicz
2009-12-12 5:54 ` Willy Tarreau
2009-12-12 6:10 ` Con Kolivas
2009-12-12 6:14 ` Willy Tarreau
2009-12-14 14:16 ` Bartlomiej Zolnierkiewicz
2009-12-18 15:44 ` BFS v0.312 configurable " Con Kolivas
2009-12-14 14:50 ` BFS v0.311 " Christoph Lameter
2009-12-15 0:56 ` Con Kolivas
2009-12-12 7:59 ` Mike Galbraith
2009-12-20 4:46 ` Bill Davidsen
2009-12-11 22:06 ` Bill Davidsen
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=1260527370.6126.53.camel@marge.simson.net \
--to=efault@gmx.de \
--cc=kernel@kolivas.org \
--cc=linux-kernel@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome