From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964854AbcDMDTB (ORCPT ); Tue, 12 Apr 2016 23:19:01 -0400 Received: from mx2.suse.de ([195.135.220.15]:47273 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933250AbcDMDSy (ORCPT ); Tue, 12 Apr 2016 23:18:54 -0400 Message-ID: <1460517531.3780.29.camel@suse.de> Subject: Re: sched: tweak select_idle_sibling to look for idle threads From: Mike Galbraith To: Chris Mason Cc: Peter Zijlstra , Ingo Molnar , Matt Fleming , linux-kernel@vger.kernel.org Date: Wed, 13 Apr 2016 05:18:51 +0200 In-Reply-To: <20160412200728.GA41928@clm-mbp.thefacebook.com> References: <20160405180822.tjtyyc3qh4leflfj@floor.thefacebook.com> <20160409190554.honue3gtian2p6vr@floor.thefacebook.com> <1460282661.4251.44.camel@suse.de> <20160410195543.fp2tpixaafsts5x3@floor.thefacebook.com> <1460350461.3870.36.camel@suse.de> <20160412003044.smr24xzuom3locvo@floor.thefacebook.com> <1460436248.3839.80.camel@suse.de> <20160412132758.7apgqqwl2c2wksy6@floor.thefacebook.com> <1460484977.5617.32.camel@suse.de> <20160412200728.GA41928@clm-mbp.thefacebook.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 Tue, 2016-04-12 at 16:07 -0400, Chris Mason wrote: > I think that if we're worried about the cost of the idle scan for this > workload, find_idlest_group() is either going to hurt much more, or not > search enough CPUs to find the idle one. find_idlest_group()? No no no, that's not what I mean at all. wake_wide() identifies loads that really want to spread out, thus turns off affine wakeups. We still call select_idle_sibling(), only difference being that target is the original cpu, not the waking cpu. Given making that wide connection bidirectional helped FB's load, it seems reasonable that passing wide information to select_idle_sibling() would have a good chance of hitting the candidate that stands to gain from a full socket scan, while also keeping that cache scrambling scan far away from the rest. > But I'm happy to try patches or other ideas, I have a fixed version of > the bitmap one going through production benchmarks now. Making that wide/full search cheap is still good, because wake_wide() also identifies interrupt sources that are waking many, so cheap wide search should increase utilization there as well. The thought was to just make the wide thing have a tad wider effect on what it already does affect.. and hope that doesn't demolish anything. -Mike