From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753077AbcGFLps (ORCPT ); Wed, 6 Jul 2016 07:45:48 -0400 Received: from mail-wm0-f49.google.com ([74.125.82.49]:36420 "EHLO mail-wm0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751828AbcGFLpr (ORCPT ); Wed, 6 Jul 2016 07:45:47 -0400 Date: Wed, 6 Jul 2016 12:45:43 +0100 From: Matt Fleming To: Mike Galbraith Cc: Dietmar Eggemann , Peter Zijlstra , Yuyang Du , LKML , Mel Gorman Subject: Re: [rfc patch] sched/fair: Use instantaneous load for fork/exec balancing Message-ID: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1467654194.3583.33.camel@gmail.com> User-Agent: Mutt/1.5.24+41 (02bc14ed1569) (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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'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.