From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757525AbcDMPFw (ORCPT ); Wed, 13 Apr 2016 11:05:52 -0400 Received: from mx2.suse.de ([195.135.220.15]:39603 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751406AbcDMPFv (ORCPT ); Wed, 13 Apr 2016 11:05:51 -0400 Message-ID: <1460559948.11954.41.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 17:05:48 +0200 In-Reply-To: <20160413143640.p52y22lvmdqkegmt@floor.thefacebook.com> References: <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> <1460517531.3780.29.camel@suse.de> <20160413134430.3s2w4dodocgislpb@floor.thefacebook.com> <1460557378.11954.22.camel@suse.de> <20160413143640.p52y22lvmdqkegmt@floor.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 Wed, 2016-04-13 at 10:36 -0400, Chris Mason wrote: > On Wed, Apr 13, 2016 at 04:22:58PM +0200, Mike Galbraith wrote: > > What exactly do you mean by failed affine wakeups? Failed because > > wake_wide() said we don't want one, or because wake_affine() said we > > can't have one? If the later, my thought bubble may have just burst, > > but it still "feels" right. > > I mean this number: > > schedstat_inc(p, se.statistics.nr_wakeups_affine_attempts); > > Is much much much higher than this number: > > schedstat_inc(p, se.statistics.nr_wakeups_affine); > > So, wake_affine said we can't have one. I made a script to sum it up > across all the threads of the webserver workload. Hm, ok, that doesn't really tell us more than there's more to the load than the 1:N bits that wake_wide() apparently did identify fairly well last go, so targeting them still might help. -Mike