From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755551AbcFQN5S (ORCPT ); Fri, 17 Jun 2016 09:57:18 -0400 Received: from mail-wm0-f66.google.com ([74.125.82.66]:35474 "EHLO mail-wm0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753166AbcFQN5Q (ORCPT ); Fri, 17 Jun 2016 09:57:16 -0400 Message-ID: <1466171828.3223.185.camel@gmail.com> Subject: Re: [patch] sched/fair: Use instantaneous load in wakeup paths From: Mike Galbraith To: Dietmar Eggemann , Yuyang Du Cc: Peter Zijlstra , LKML Date: Fri, 17 Jun 2016 15:57:08 +0200 In-Reply-To: <5763D706.5020902@arm.com> References: <1465891111.1694.13.camel@gmail.com> <20160614224218.GK8105@intel.com> <1465974093.4219.14.camel@gmail.com> <1466077593.2278.23.camel@gmail.com> <1466078681.2278.26.camel@gmail.com> <1466080888.2278.30.camel@gmail.com> <1466144462.3223.102.camel@gmail.com> <5763D706.5020902@arm.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 Fri, 2016-06-17 at 11:55 +0100, Dietmar Eggemann wrote: > On 17/06/16 07:21, Mike Galbraith wrote: > > Here are some schbench runs on an 8x8 box to show that longish > > run/sleep period corner I mentioned. > > > > vogelweide:~/:[1]# for i in `seq 5`; do schbench -m 8 -t 1 -a -r 10 2>&1 | grep 'threads 8'; done > > cputime 30000 threads 8 p99 68 > > cputime 30000 threads 8 p99 46 > > cputime 30000 threads 8 p99 46 > > cputime 30000 threads 8 p99 45 > > cputime 30000 threads 8 p99 49 > > vogelweide:~/:[0]# echo NO_WAKE_INSTANTANEOUS_LOAD > /sys/kernel/debug/sched_features > > vogelweide:~/:[0]# for i in `seq 5`; do schbench -m 8 -t 1 -a -r 10 2>&1 | grep 'threads 8'; done > > cputime 30000 threads 8 p99 9968 > > cputime 30000 threads 8 p99 10224 > > vogelweide:~/:[0]# > > > > Is this the influence of wake_affine using instantaneous load now too or > did you set SD_BALANCE_WAKE on sd's or both? It's likely just the fork bits, I didn't turn on SD_BALANCE_WAKE. > > > Using instantaneous load, we fill the box every time, without, we stack > > every time. This was with Peter's select_idle_sibling() rewrite > > applied as well, but you can see that it does matter. > > > > That doesn't mean I think my patch should immediately fly upstream > > 'course, who knows, there may be a less messy way to deal with it, or, > > as already stated, maybe it just doesn't matter enough to the real > > world to even bother with. > > IMHO, if it would be possible to get rid of sd->wake_idx, > sd->forkexec_idx, the implementation would be less messy. Is there > anyone changing these values to something other that the default 0? Dunno. Doesn't matter much until we answer the question are the numbers we're using good enough, or are they not. Hackbench and schbench say we can certainly distribute load better by looking at the real deal instead of a ball of fuzz (a scheduler dust monster;), but how long have we been doing that, and how many real world complaints do we have? The schbench thing is based on a real world load, but the real world complaint isn't the fork distribution thing that schbench demonstrates, that's a periodic load corner, not the we're waking to busy CPUs while there are idle CPUs available that Facebook is griping about. So we have zero real world complaints, we have hackbench moving because the ball of fuzz got reshaped, and we have the bumpy spot that schbench hits with or without the bugfix that caused hackbench to twitch. -Mike