From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753120AbcGFMVh (ORCPT ); Wed, 6 Jul 2016 08:21:37 -0400 Received: from mail-wm0-f65.google.com ([74.125.82.65]:34002 "EHLO mail-wm0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751108AbcGFMVf (ORCPT ); Wed, 6 Jul 2016 08:21:35 -0400 Message-ID: <1467807692.3630.25.camel@gmail.com> Subject: Re: [rfc patch] sched/fair: Use instantaneous load for fork/exec balancing From: Mike Galbraith To: Matt Fleming Cc: Dietmar Eggemann , Peter Zijlstra , Yuyang Du , LKML , Mel Gorman Date: Wed, 06 Jul 2016 14:21:32 +0200 In-Reply-To: <20160706114543.GQ8415@codeblueprint.co.uk> References: <1465891111.1694.13.camel@gmail.com> <5760115C.7040306@arm.com> <1465922407.3626.21.camel@gmail.com> <5761752A.6000606@arm.com> <20160704150452.GP8415@codeblueprint.co.uk> <1467654194.3583.33.camel@gmail.com> <20160706114543.GQ8415@codeblueprint.co.uk> 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 Wed, 2016-07-06 at 12:45 +0100, Matt Fleming wrote: > On Mon, 04 Jul, at 07:43:14PM, Mike Galbraith wrote: > > On Mon, 2016-07-04 at 16:04 +0100, Matt Fleming wrote: > > > > > But we can optimise the special case of dequeueing the last entity and > > > reset ::runnable_load_avg early, which gives a performance improvement > > > to workloads that trigger the load balancer, such as fork-heavy > > > applications when SD_BALANCE_FORK is set, because it gives a more up > > > to date view of how busy the cpu is. > > > > Begs the question: what's so special about this case vs any other > > dequeue/enqueue? > > All that makes this special is that this is the behaviour seen when > running hackbench - initial heavy forking by some master task which > eventually wakes everyone up. So you get this huge sequence of "fork, > enqueue, run, dequeue". Yes, it's a complete hack. I'm a bit concerned that poking holes in the logic to make hackbench a bit happier will eradicate the calming effect that avg/aging business has on load balancing, inflicting harm on real world loads. That would be a bad trade. > > I've given up on this as being a waste of time. Either you serialize > > everything box wide (not!) and can then make truly accurate evaluations > > of state, or you're making an educated guess based upon what once was. > > > > The only place I've seen where using the average consistently has > > issues is with a longish period periodic load (schbench). > > I'm open to any suggestion that restores performance to that seen > before commit 0905f04eb21f, whether or not that involves changing how > load averages are used. None here. That hackbench was fond of that dead bug is just too bad, as Peter seldom resurrects bugs once swatted :) FWIW, I took a peek at distribution on my little desktop box while fiddling, and while it was not a pretty flat line, it wasn't a stock market crash graph either. -Mike