From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED,USER_AGENT_NEOMUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DF0A7C28CF6 for ; Fri, 3 Aug 2018 08:19:00 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 9F1A52172A for ; Fri, 3 Aug 2018 08:19:00 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9F1A52172A Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732078AbeHCKOJ (ORCPT ); Fri, 3 Aug 2018 06:14:09 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:39658 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727682AbeHCKOJ (ORCPT ); Fri, 3 Aug 2018 06:14:09 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 4705F7A9; Fri, 3 Aug 2018 01:18:58 -0700 (PDT) Received: from queper01-lin (queper01-lin.Emea.Arm.com [10.4.13.27]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 520243F5BA; Fri, 3 Aug 2018 01:18:54 -0700 (PDT) Date: Fri, 3 Aug 2018 09:18:52 +0100 From: Quentin Perret To: Vincent Guittot Cc: Peter Zijlstra , "Rafael J. Wysocki" , linux-kernel , "open list:THERMAL" , "gregkh@linuxfoundation.org" , Ingo Molnar , Dietmar Eggemann , Morten Rasmussen , Chris Redpath , Patrick Bellasi , Valentin Schneider , Thara Gopinath , viresh kumar , Todd Kjos , Joel Fernandes , "Cc: Steve Muckle" , adharmap@quicinc.com, "Kannan, Saravana" , pkondeti@codeaurora.org, Juri Lelli , Eduardo Valentin , Srinivas Pandruvada , currojerez@riseup.net, Javi Merino Subject: Re: [PATCH v5 09/14] sched: Add over-utilization/tipping point indicator Message-ID: <20180803081850.hj7bp5ognuywapmd@queper01-lin> References: <20180802141424.ju4jxxbk6pxw3kyq@queper01-lin> <20180802153035.vjtmqwdwujvt7ojs@queper01-lin> <20180802160009.uhwwj3tqrqmv7q5a@queper01-lin> <20180802161027.v2ctgscuc4uxbb7u@queper01-lin> <20180802165924.7ywgoxj2jwftxycz@queper01-lin> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20171215 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Friday 03 Aug 2018 at 09:48:47 (+0200), Vincent Guittot wrote: > On Thu, 2 Aug 2018 at 18:59, Quentin Perret wrote: > I'm not really concerned about re-enabling load balance but more that > the effort of packing of tasks in few cpus/clusters that EAS tries to > do can be broken for every new task. Well, re-enabling load balance immediately would break the nice placement that EAS found, because it would shuffle all tasks around and break the packing strategy. Letting that sole new task go in find_idlest_cpu() shouldn't impact the placement of existing tasks. That might have an energy cost for that one task, yes, but it's really hard to do anything smarter with new tasks IMO ... EAS simply can't work without a utilization value. > So I wonder what is better for EAS : Make sure to efficiently spread > newly created tasks in cas of fork bomb or try to not break EAS task > placement with every newly created tasks That shouldn't break the placement per se, we're just making one temporary exception for new tasks. What do you think 'the right thing' to do is ? To just put new tasks on prev_cpu or something like that ? That might help some use-cases I suppose, but will probably harm others ... I'm just not too keen on making assumptions about the size of new tasks, that's all. But I'm definitely open to ideas if there is something smarter we can do. Thanks, Quentin