From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932291AbbGGPZN (ORCPT ); Tue, 7 Jul 2015 11:25:13 -0400 Received: from mail-wg0-f52.google.com ([74.125.82.52]:36217 "EHLO mail-wg0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756969AbbGGPY5 (ORCPT ); Tue, 7 Jul 2015 11:24:57 -0400 Message-ID: <1436282695.1836.104.camel@gmail.com> Subject: Re: [patch] Re: [PATCH RESEND] sched: prefer an idle cpu vs an idle sibling for BALANCE_WAKE From: Mike Galbraith To: Josef Bacik Cc: Peter Zijlstra , riel@redhat.com, mingo@redhat.com, linux-kernel@vger.kernel.org, morten.rasmussen@arm.com, kernel-team Date: Tue, 07 Jul 2015 17:24:55 +0200 In-Reply-To: <559BD6C6.8070104@fb.com> References: <1432761736-22093-1-git-send-email-jbacik@fb.com> <20150528102127.GD3644@twins.programming.kicks-ass.net> <20150528110514.GR18673@twins.programming.kicks-ass.net> <1434087305.3674.26.camel@gmail.com> <5581B70D.2000800@fb.com> <1434588939.3444.25.camel@gmail.com> <55823F33.7040005@fb.com> <1434600765.3393.9.camel@gmail.com> <55957871.7080906@fb.com> <1435905658.6418.52.camel@gmail.com> <1436025462.17152.37.camel@gmail.com> <1436080661.22930.22.camel@gmail.com> <1436159590.5850.27.camel@gmail.com> <559A91F4.7000903@fb.com> <1436207790.2940.30.camel@gmail.com> <559AD9CE.4090309@fb.com> <1436241678.1836.29.camel@gmail.com> <1436262224.1836.74.camel@gmail.com> <559BD6C6.8070104@fb.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.12.11 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, 2015-07-07 at 09:40 -0400, Josef Bacik wrote: > The WAKE_WIDE_IDLE run was basically the same so I'm good with the KISS > version. I'll run that through the load tests this morning and let you > know how it goes. I'm still seeing a slight regression at lower RPS, > but it's like 1-2%, compared to ~15%. If I'm to believe pgbench, and configs really are as close as they should be, there may be something between 3.12 and master which could account for your delta and then some. I may go hunting.. heck, if I trusted pgbench I would be hunting. patched SLE (resembles 3.12 if you squint) postgres@nessler:~> pgbench.sh clients 12 tps = 134795.901777 clients 24 tps = 156955.584523 clients 36 tps = 161450.044316 clients 48 tps = 171181.069044 clients 60 tps = 157896.858179 clients 72 tps = 155816.051709 clients 84 tps = 152456.003468 clients 96 tps = 121129.848008 patched master postgres@nessler:~> pgbench.sh clients 12 tps = 120793.023637 clients 24 tps = 144668.961468 clients 36 tps = 156705.239251 clients 48 tps = 152004.886893 clients 60 tps = 138582.113864 clients 72 tps = 136286.891104 clients 84 tps = 137420.986043 clients 96 tps = 135199.060242