Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755876AbbFCP6K (ORCPT ); Wed, 3 Jun 2015 11:58:10 -0400 Received: from mx0a-00082601.pphosted.com ([67.231.145.42]:36358 "EHLO mx0a-00082601.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754389AbbFCP6E (ORCPT ); Wed, 3 Jun 2015 11:58:04 -0400 Message-ID: <556F23E5.5020107@fb.com> Date: Wed, 3 Jun 2015 11:57:25 -0400 From: Josef Bacik User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Mike Galbraith , Peter Zijlstra CC: Rik van Riel , , , , 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> <556F0B5E.6030805@redhat.com> <1433341448.1495.4.camel@twins> <1433345444.3343.21.camel@gmail.com> In-Reply-To: <1433345444.3343.21.camel@gmail.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [192.168.52.123] X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151,1.0.33,0.0.0000 definitions=2015-06-03_08:2015-06-03,2015-06-03,1970-01-01 signatures=0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1492 Lines: 33 On 06/03/2015 11:30 AM, Mike Galbraith wrote: > On Wed, 2015-06-03 at 16:24 +0200, Peter Zijlstra wrote: >> On Wed, 2015-06-03 at 10:12 -0400, Rik van Riel wrote: >> >>> 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. >> >> For his workload; I'm sure I can find a workload where it hurts. >> >> In fact, I'm fairly sure Mike knows one from the top of his head, seeing >> how he's the one playing about trying to shrink that idle search :-) > > Like anything where scheduling latency doesn't heavily dominate. Even > if searching were free, bounces aren't, even for the very light. > If scheduling latency doesn't hurt then making the search shouldn't matter should it? I get that migrations aren't free, but it seems like they can't hurt that much. This application is huge, it's our webserver, we're doing like 400 requests per second on these things, and hands down moving stuff to idle cpus is beating the pants off of staying on the same cpu. Is there a specific workload I could build a test for that you think this approach would hurt? 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/