Subject: Re: BFS v0.311 CPU scheduler for 2.6.32
From: Mike Galbraith <efault@gmx.de>
To: Con Kolivas <kernel@kolivas.org>
Cc: linux-kernel@vger.kernel.org
In-Reply-To: <200912111124.18118.kernel@kolivas.org>
References: <200912111124.18118.kernel@kolivas.org>
Content-Type: text/plain
Date: Fri, 11 Dec 2009 11:29:30 +0100
Message-Id: <1260527370.6126.53.camel@marge.simson.net>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1204
Lines: 25

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/