From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1753281AbbLNRwF (ORCPT <rfc822;w@1wt.eu>);
	Mon, 14 Dec 2015 12:52:05 -0500
Received: from mail-pa0-f43.google.com ([209.85.220.43]:33675 "EHLO
	mail-pa0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1752601AbbLNRwC (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Mon, 14 Dec 2015 12:52:02 -0500
From: bsegall@google.com
To: Morten Rasmussen <morten.rasmussen@arm.com>
Cc: Dietmar Eggemann <dietmar.eggemann@arm.com>,
        Andrey Ryabinin <aryabinin@virtuozzo.com>,
        Peter Zijlstra <peterz@infradead.org>, mingo@redhat.com,
        linux-kernel@vger.kernel.org, yuyang.du@intel.com,
        Paul Turner <pjt@google.com>
Subject: Re: [PATCH] sched/fair: fix mul overflow on 32-bit systems
References: <1449838518-26543-1-git-send-email-aryabinin@virtuozzo.com>
	<20151211132551.GO6356@twins.programming.kicks-ass.net>
	<20151211133612.GG6373@twins.programming.kicks-ass.net>
	<566AD6E1.2070005@virtuozzo.com>
	<20151211175751.GA27552@e105550-lin.cambridge.arm.com>
	<566B16D8.2060109@arm.com>
	<xm26wpsk3ian.fsf@sword-of-the-dawn.mtv.corp.google.com>
	<20151214123253.GA9870@e105550-lin.cambridge.arm.com>
Date: Mon, 14 Dec 2015 09:51:58 -0800
In-Reply-To: <20151214123253.GA9870@e105550-lin.cambridge.arm.com> (Morten
	Rasmussen's message of "Mon, 14 Dec 2015 12:32:54 +0000")
Message-ID: <xm26oads3old.fsf@sword-of-the-dawn.mtv.corp.google.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Morten Rasmussen <morten.rasmussen@arm.com> writes:

> On Fri, Dec 11, 2015 at 11:18:56AM -0800, bsegall@google.com wrote:
>> So uh yeah, my initial impression is "rip it out", but if being
>> immediately-correct is important in the case of one task being most of
>> the utilization, rather than when it is more evenly distributed, it
>> would probably make more sense to instead put in the add-on-enqueue
>> code.
>
> I would prefer if stayed in. There are several patch sets posted for
> review that use util_avg.


Yeah, I missed the attach call on enqueue, which means my argument is
basically invalid, as the code is sensible enough at the moment ("rip it
out" was meant to refer only to the remove-on-migrate, not the whole
util_avg).