From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751300AbcEHIJO (ORCPT ); Sun, 8 May 2016 04:09:14 -0400 Received: from mx2.suse.de ([195.135.220.15]:58242 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751157AbcEHII7 (ORCPT ); Sun, 8 May 2016 04:08:59 -0400 Message-ID: <1462694935.4155.83.camel@suse.de> Subject: Re: sched: tweak select_idle_sibling to look for idle threads From: Mike Galbraith To: Yuyang Du Cc: Peter Zijlstra , Chris Mason , Ingo Molnar , Matt Fleming , linux-kernel@vger.kernel.org Date: Sun, 08 May 2016 10:08:55 +0200 In-Reply-To: <20160507012417.GK16093@intel.com> References: <20160405180822.tjtyyc3qh4leflfj@floor.thefacebook.com> <20160409190554.honue3gtian2p6vr@floor.thefacebook.com> <20160430124731.GE2975@worktop.cust.blueprintrf.com> <1462086753.9717.29.camel@suse.de> <20160501085303.GF2975@worktop.cust.blueprintrf.com> <1462094425.9717.45.camel@suse.de> <20160507012417.GK16093@intel.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.16.5 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, 2016-05-07 at 09:24 +0800, Yuyang Du wrote: > On Sun, May 01, 2016 at 11:20:25AM +0200, Mike Galbraith wrote: > > Playing with Chris' benchmark, seems the biggest problem is that we > > don't buddy up waker of many and it's wakees in a node.. ie the wake > > wide thing isn't necessarily our friend when there are multiple wakers > > of many. If I run an instance per node with one mother of all work in > > autobench mode, it works exactly as you'd expect, game over is when > > wakees = socket size. It never get's near that point if I let things > > wander, it beats itself up well before we get there. > > Maybe give the criteria a bit margin, not just wakees tend to equal llc_size, > but the numbers are so wild to easily break the fragile condition, like: Seems lockless traversal and averages just lets multiple CPUs select the same spot. An atomic reservation (feature) when looking for an idle spot (also for fork) might fix it up. Run the thing as RT, push/pull ensures that it reaches box saturation regardless of the number of messaging threads, whereas with fair class, any number > 1 will certainly stack tasks before the box is saturated. -Mike