Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755899AbbFCOM4 (ORCPT ); Wed, 3 Jun 2015 10:12:56 -0400 Received: from mx1.redhat.com ([209.132.183.28]:43214 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752903AbbFCOMs (ORCPT ); Wed, 3 Jun 2015 10:12:48 -0400 Message-ID: <556F0B5E.6030805@redhat.com> Date: Wed, 03 Jun 2015 10:12:46 -0400 From: Rik van Riel User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Josef Bacik , Peter Zijlstra CC: mingo@redhat.com, linux-kernel@vger.kernel.org, umgwanakikbuti@gmail.com, morten.rasmussen@arm.com, kernel-team Subject: Re: [PATCH RESEND] sched: prefer an idle cpu vs an idle sibling for BALANCE_WAKE References: <1432761736-22093-1-git-send-email-jbacik@fb.com> <20150528102127.GD3644@twins.programming.kicks-ass.net> <20150528110514.GR18673@twins.programming.kicks-ass.net> <5568D43D.20703@fb.com> <556CB4A8.1050509@fb.com> <1433191354.11346.22.camel@twins> <556DE3FB.9020400@fb.com> In-Reply-To: <556DE3FB.9020400@fb.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1410 Lines: 36 On 06/02/2015 01:12 PM, Josef Bacik wrote: > But now that I re-read your response I think this is even more what you > were worried about than less. > > Basically it comes down to if sd isn't set then we get shit performance. > I realize that this magic to find an idle cpu when sd is set is pretty > heavy handed, but it's obviously helpful in our case. Ingo and Peter appear to be worried that searching through too many idle CPUs leads to bad performance. Your test results seem to indicate that finding an idle CPU really really helps performance. There is a policy vs mechanism thing here. Ingo and Peter are worried about the overhead in the mechanism of finding an idle CPU. Your measurements show that the policy of finding an idle CPU is the correct one. Can we make the policy change now, and optimize the mechanism later? > So let me ask this question. When do we want to do the heavy handed > search and when do we not? With WAKE_AFFINE what is our ultimate goal > vs the other SD's? If we don't have an sd that matches our sd_flags > what should we be doing, should we just go with whatever cpu we're on > and carry on? Thanks, > > Josef -- 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/