Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932519AbbFCUen (ORCPT ); Wed, 3 Jun 2015 16:34:43 -0400 Received: from mx0a-00082601.pphosted.com ([67.231.145.42]:64669 "EHLO mx0a-00082601.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932421AbbFCUef (ORCPT ); Wed, 3 Jun 2015 16:34:35 -0400 Message-ID: <556F64B9.1050603@fb.com> Date: Wed, 3 Jun 2015 16:34:01 -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 CC: Peter Zijlstra , 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> <556F23E5.5020107@fb.com> <1433350386.3996.15.camel@gmail.com> <556F3677.2090206@fb.com> <1433353411.3407.15.camel@gmail.com> In-Reply-To: <1433353411.3407.15.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_11: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: 1652 Lines: 36 On 06/03/2015 01:43 PM, Mike Galbraith wrote: > On Wed, 2015-06-03 at 13:16 -0400, Josef Bacik wrote: > >> Eesh ok, do you happen to remember how you ran tbench so I can add it to >> my tests here? In addition to fixing this problem we're also interested >> in tracking performance of new kernels so we don't have to do this "what >> the hell went wrong in the last 6 releases" dance every year, so I'm >> throwing every performance thing we find useful in our test >> infrastructure. Thanks, >> >> Josef > > Start a tbench server, then tbench -t 30 1 localhost. You're unlikely > to find anything as painful as that bouncing cow bug was, but you won't > have to look hard at all to find bounce pain. > > There are also other loads like your server where waking to an idle cpu > dominates all else, pgbench is one of those. In that case, you've got a > 1:N waker/wakee relationship, and what matters above ALL else is when > the mother of all work (the single server thread) wants a CPU, it had > better get it NOW, else the load stalls. Likewise, 'mom' being > preempted hurts truckloads. Perhaps your server has a similar thing > going on, keeping wakees the hell away from the waker rules all. > Yeah our server has two waker threads (one per numa node) and then the N number of wakee threads. I'll run tbench and pgbench with the new patches and see if there's a degredation. 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/