From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753958AbcFPJB1 (ORCPT ); Thu, 16 Jun 2016 05:01:27 -0400 Received: from foss.arm.com ([217.140.101.70]:42127 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753834AbcFPJBV (ORCPT ); Thu, 16 Jun 2016 05:01:21 -0400 Subject: Re: [rfc patch] sched/fair: Use instantaneous load for fork/exec balancing To: Mike Galbraith , Peter Zijlstra References: <1465891111.1694.13.camel@gmail.com> <5760115C.7040306@arm.com> <1465922407.3626.21.camel@gmail.com> <5761752A.6000606@arm.com> <1466006609.4219.40.camel@gmail.com> <5761A677.3060609@arm.com> <1466048008.2780.5.camel@gmail.com> Cc: Yuyang Du , LKML From: Dietmar Eggemann Message-ID: <57626ADD.8080203@arm.com> Date: Thu, 16 Jun 2016 10:01:17 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <1466048008.2780.5.camel@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 16/06/16 04:33, Mike Galbraith wrote: > On Wed, 2016-06-15 at 20:03 +0100, Dietmar Eggemann wrote: > >> Isn't there a theoretical problem with the scale_load() on CONFIG_64BIT >> machines on tip/sched/core? load.weight has a higher resolution than >> runnable_load_avg (and so the values in the rq->cpu_load[] array). >> Theoretically because [forkexec|wake]_idx is 0 so [target|source]_load() >> is nothing else than weighted_cpuload(). > > I see a not so theoretical problem with my rfc in that I forgot to > scale_load_down() if that's what you mean. Yup. Theoretical in the sense that this_load and min_load will be affected both the same way as long as load_idx = 0. > > (changes nothing, reality was just extra special unadulterated;) Agreed. > > -Mike >