From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933102AbcFPDde (ORCPT ); Wed, 15 Jun 2016 23:33:34 -0400 Received: from mail-wm0-f45.google.com ([74.125.82.45]:38045 "EHLO mail-wm0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753224AbcFPDdb (ORCPT ); Wed, 15 Jun 2016 23:33:31 -0400 Message-ID: <1466048008.2780.5.camel@gmail.com> Subject: Re: [rfc patch] sched/fair: Use instantaneous load for fork/exec balancing From: Mike Galbraith To: Dietmar Eggemann , Peter Zijlstra Cc: Yuyang Du , LKML Date: Thu, 16 Jun 2016 05:33:28 +0200 In-Reply-To: <5761A677.3060609@arm.com> 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> 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-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. (changes nothing, reality was just extra special unadulterated;) -Mike