Received: by 2002:a05:6358:1087:b0:cb:c9d3:cd90 with SMTP id j7csp644310rwi; Wed, 26 Oct 2022 05:37:55 -0700 (PDT) X-Google-Smtp-Source: AMsMyM7/Yq71QkNaLKmg2xP8WJao2uUOooCV+UC1FrUDL48rIFreR/hCBOaw6J4/Vm5qtBTIQsjd X-Received: by 2002:a17:907:b01:b0:78d:ce3d:905d with SMTP id h1-20020a1709070b0100b0078dce3d905dmr36854812ejl.45.1666787875653; Wed, 26 Oct 2022 05:37:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666787875; cv=none; d=google.com; s=arc-20160816; b=Ggoxz/h8QYIzs6x0+kvz2NgPNQjaRJXHrxYodHWN7wvVcJd4GPvWNXgXtG9ebEXfJr Z5xXj4C7YnMVwky69A/M2h/uPuE+bEIRSfP3DDTDfA6LGqPAJSHG7OvaZd4lm1t5FFn9 xKXVPpNW1GJePUJJ/KZ4j+h2AyTsP/WiT/EPulDb8vPdVm0pehyBGyTJJaX7lJLQRYmL BWJAmWczhMAVrD+l2Bwr7IG5pJOh3VmK4yarYs/z2OQe66qLf/VH4lQtfeztKTQzLsXE Fa8b4mYzkaiXPOhCOOez9zr1fs/ajsRzO2U4fICYFb9xUGRs59Vh4WlVN4aCW2aCXmQd GiDw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id; bh=CFHz6vrWry4416PljzXz1Ck8EghIc7Yg5Vwo1cUcJBk=; b=yx6tj5t1w8yQSL2vMvZjgksSCSEXeX4Sh+gOB1wCgglO6C4Mb3+S3q4Ezh4Sjqc56I MAu50QBjlD5nphHI0p8SEWF799yCk67mivzLEtnHmfTb5T4v3E9RAGGi6cpXsjbqRGLq uRVao2u7ypHi4G2hNh3YQ+boTZK4lCi8g1B3OUDVtHH7Uc2PfRKQAOxWoRwVmnYgg+Xt ac/G1Ycj/03/iRCXDzIF/j0E6Ksx6Vpr7YMc9t+jGTqmq3xQsoth6XH4bsVbGgz2B+LF RuPfavlkOhdG+VqpeT0r9vrIVrisVpDLjGqAwG/Cd8+q2icm4+7GmJzPC69Qxgrr5AAF svxw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id jy15-20020a170907762f00b00783a5f78700si4860604ejc.226.2022.10.26.05.37.28; Wed, 26 Oct 2022 05:37:55 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232865AbiJZMXL (ORCPT + 99 others); Wed, 26 Oct 2022 08:23:11 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38066 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232748AbiJZMXJ (ORCPT ); Wed, 26 Oct 2022 08:23:09 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 4F1908F240; Wed, 26 Oct 2022 05:23:08 -0700 (PDT) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id F022623A; Wed, 26 Oct 2022 05:23:13 -0700 (PDT) Received: from [10.57.2.24] (unknown [10.57.2.24]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 2B3563F71A; Wed, 26 Oct 2022 05:23:05 -0700 (PDT) Message-ID: <62a7cafc-13d6-5341-0128-420db7d5da8c@arm.com> Date: Wed, 26 Oct 2022 13:23:03 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: [PATCH] sched/topology: Remove EM_MAX_COMPLEXITY limit Content-Language: en-US To: Pierre Gondois Cc: Ionela.Voinescu@arm.com, Jonathan Corbet , Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Daniel Bristot de Oliveira , Valentin Schneider , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org References: <20220812101620.627838-1-pierre.gondois@arm.com> From: Lukasz Luba In-Reply-To: <20220812101620.627838-1-pierre.gondois@arm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,NICE_REPLY_A, RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Pierre, On 8/12/22 11:16, Pierre Gondois wrote: > From: Pierre Gondois > > The Energy Aware Scheduler (EAS) estimates the energy consumption > of placing a task on different CPUs. The goal is to minimize this > energy consumption. Estimating the energy of different task placements > is increasingly complex with the size of the platform. To avoid having > a slow wake-up path, EAS is only enabled if this complexity is low > enough. > > The current complexity limit was set in: > commit b68a4c0dba3b1 ("sched/topology: Disable EAS on inappropriate > platforms"). > base on the first implementation of EAS, which was re-computing > the power of the whole platform for each task placement scenario, cf: > commit 390031e4c309 ("sched/fair: Introduce an energy estimation helper > function"). > but the complexity of EAS was reduced in: > commit eb92692b2544d ("sched/fair: Speed-up energy-aware wake-ups") > and find_energy_efficient_cpu() (feec) algorithm was updated in: > commit 3e8c6c9aac42 ("sched/fair: Remove task_util from effective > utilization in feec()") > > find_energy_efficient_cpu() (feec) is now doing: > feec() > \_ for_each_pd(pd) [0] > // get max_spare_cap_cpu and compute_prev_delta > \_ for_each_cpu(pd) [1] > > \_ get_pd_busy_time(pd) [2] > \_ for_each_cpu(pd) > > // evaluate pd energy without the task > \_ get_pd_max_util(pd, -1) [3.0] > \_ for_each_cpu(pd) > \_ compute_energy(pd, -1) > \_ for_each_ps(pd) > > // evaluate pd energy with the task on prev_cpu > \_ get_pd_max_util(pd, prev_cpu) [3.1] > \_ for_each_cpu(pd) > \_ compute_energy(pd, prev_cpu) > \_ for_each_ps(pd) > > // evaluate pd energy with the task on max_spare_cap_cpu > \_ get_pd_max_util(pd, max_spare_cap_cpu) [3.2] > \_ for_each_cpu(pd) > \_ compute_energy(pd, max_spare_cap_cpu) > \_ for_each_ps(pd) > > [3.1] happens only once since prev_cpu is unique. To have an upper > bound of the complexity, [3.1] is taken into account for all pds. > So with the same definitions for nr_pd, nr_cpus and nr_ps, > the complexity is of: > nr_pd * (2 * [nr_cpus in pd] + 3 * ([nr_cpus in pd] + [nr_ps in pd])) > [0] * ( [1] + [2] + [3.0] + [3.1] + [3.2] ) > = 5 * nr_cpus + 3 * nr_ps > > The complexity limit was set to 2048 in: > commit b68a4c0dba3b1 ("sched/topology: Disable EAS on inappropriate > platforms") > to make "EAS usable up to 16 CPUs with per-CPU DVFS and less than 8 > performance states each". For the same platform, the complexity would > actually be of: > 5 * 16 + 3 * 7 = 101 > > Since the EAS complexity was greatly reduced, bigger platforms can > handle EAS. For instance, a platform with 256 CPUs with 256 > performance states each would reach it. To reflect this improvement, > remove the EAS complexity check. > > Signed-off-by: Pierre Gondois > --- > Documentation/scheduler/sched-energy.rst | 37 ++-------------------- > kernel/sched/topology.c | 39 ++---------------------- > 2 files changed, 6 insertions(+), 70 deletions(-) > The patch looks good for both: documentation bit and code removal. We have a new safety checks inside the Energy Model during the setup of EM for perf domian, even a more strict and precised (32bit arch or 64bit arch) to no overflow in our calculations (when we estimate energy). This is documented in the Energy Model, so IMO you can easily drop this paragraph as the patch does. The same applies to the checks in the code. Reviewed-by: Lukasz Luba