Messages in this thread | | | Subject | Re: BFS v0.311 CPU scheduler for 2.6.32 | From | Mike Galbraith <> | Date | Fri, 11 Dec 2009 11:29:30 +0100 |
| |
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
| |