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=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no 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 81632C47094 for ; Thu, 10 Jun 2021 12:40:48 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 6112E613FF for ; Thu, 10 Jun 2021 12:40:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230297AbhFJMmn (ORCPT ); Thu, 10 Jun 2021 08:42:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49502 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230001AbhFJMmm (ORCPT ); Thu, 10 Jun 2021 08:42:42 -0400 Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CC2DEC061760 for ; Thu, 10 Jun 2021 05:40:45 -0700 (PDT) Received: by mail-lf1-x12a.google.com with SMTP id n12so3008348lft.10 for ; Thu, 10 Jun 2021 05:40:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Z9GTMqOXMzmRTvDvHxm6+Se4ETluKcj7GUfbg2SHXm8=; b=aOwKXTB+xjFL+Z+W9pzjvMPI0ondEQou4VIrrwycbLhvR3HJW4ArPNNko0VQlAPdbo XQHmUSFLlTGnrShlUGSZWa1RtGx3px//lOuTRyrY3daR8HLFWi+Ey89ge7QEapv4zjrg +7zbb1BxAZ2NPAZ6qBhdXqx8N2SflSCeCxBLEACF9D0sC/FYIFxXgLAc0F74tbuD5oAr twKkYxQqqyuTH2kjQ2luX64gjhXjvEAYYtb4xZVwecx6rPdgQZU6JLJu96u14roLnw6N OnIH5ffDKwvJv57Qg731VTDnTYODKaKr32O1du3BiFQFBW3hlAy37cs9xiBImbf2ZVR1 Mfyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Z9GTMqOXMzmRTvDvHxm6+Se4ETluKcj7GUfbg2SHXm8=; b=stIyReC56Ik402Rq99Ko+8/v0FbGjpbsFTyvH9yoOh2vq8CFk/fmhpCisknTYuhi4D QJ4C1bPIjk5UKVIaNN6tXkgKnLsiErcA0FmaA+t6H6xzLa0T6TVN8dzllS+cDSV96ozD mDFhB85BNiDPNSTDbj8nrGBaEmfkBfSmrJOcM/nbSJJQJHvzg7ACVfc+sW0ml7JCdBAM 7VYQ1DAzjNJtTEGXNbsDbPUkyArVaju/K/NK1s8YrPg78+tKAUen076PoyJndKSfpjzw acBP9cgrup8Ub6hxb4Sc/h5aTSXmrWXjbaIVtJNeAu3NScBnjKFjMAsuXDB+MM/E+RmX EiRw== X-Gm-Message-State: AOAM532DGcUlX39p3v2wETQxXTNT+VNl72jDGO/WdtK3KnyF9RTmkt4p CIo48SqvquHM5X/DS0ruvMOGhtwLrL7qx3mgd0VQ1w== X-Google-Smtp-Source: ABdhPJzqqRmuWZBnW38f20ywqx99Uh+wq0Jh0gy0oyNQUNhdETu33NoyHJsnUGF72Kkc7eYhHO0PkOiUrOPyYSqhOzA= X-Received: by 2002:ac2:5fc7:: with SMTP id q7mr1839577lfg.286.1623328844135; Thu, 10 Jun 2021 05:40:44 -0700 (PDT) MIME-Version: 1.0 References: <20210604080954.13915-1-lukasz.luba@arm.com> <20210604080954.13915-2-lukasz.luba@arm.com> <2f2fc758-92c6-5023-4fcb-f9558bf3369e@arm.com> <905f1d29-50f9-32be-4199-fc17eab79d04@arm.com> <3cfa5690-644b-ba80-3fc3-7c5a3f292e70@arm.com> In-Reply-To: From: Vincent Guittot Date: Thu, 10 Jun 2021 14:40:32 +0200 Message-ID: Subject: Re: [PATCH v2 1/2] sched/fair: Take thermal pressure into account while estimating energy To: Lukasz Luba Cc: Dietmar Eggemann , linux-kernel , "open list:THERMAL" , Peter Zijlstra , "Rafael J. Wysocki" , Viresh Kumar , Quentin Perret , Vincent Donnefort , Beata Michalska , Ingo Molnar , Juri Lelli , Steven Rostedt , segall@google.com, Mel Gorman , Daniel Bristot de Oliveira Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 10 Jun 2021 at 14:30, Lukasz Luba wrote: > > > > On 6/10/21 1:19 PM, Vincent Guittot wrote: > > On Thu, 10 Jun 2021 at 12:37, Lukasz Luba wrote: > >> > >> > >> > >> On 6/10/21 11:07 AM, Dietmar Eggemann wrote: > >>> On 10/06/2021 11:04, Lukasz Luba wrote: > >>>> > >> > >> [snip] > >> > >>>> Not always, it depends on thermal governor decision, workload and > >>>> 'power actors' (in IPA naming convention). Then it depends when and how > >>>> hard you clamp the CPUs. They (CPUs) don't have to be always > >>>> overutilized, they might be even 50-70% utilized but the GPU reduced > >>>> power budget by 2 Watts, so CPUs left with only 1W. Which is still OK > >>>> for the CPUs, since they are only 'feeding' the GPU with new 'jobs'. > >>> > >>> All this pretty much confines the usefulness of you proposed change. A > >>> precise description of it with the patches is necessary to allow people > >>> to start from there while exploring your patches. > >> > >> OK, I see your point. > >> > >> [snip] > >> > >>>> True, I hope this description above would help to understand the > >>>> scenario. > >>> > >>> This description belongs in the patch header. The scenario in which your > >>> functionality would improve things has to be clear. > >>> I'm sure that not everybody looking at this patches is immediately aware > >>> on how IPA setups work and which specific setup you have in mind here. > >> > >> Agree. I will add this description into the patch header for v3. > >> > >> [snip] > >> > >>>> > >>>> Yes, this code implementation tries to address those issues. > >>> > >>> The point I was making here is: why using the PELT signal > >>> thermal_load_avg() and not per_cpu(thermal_pressure, cpu) directly, > >>> given the fact that the latter perfectly represents the frequency clamping? > >>> > >> > >> Good question. I wanted to be aligned with other parts in the fair.c > >> like cpu_capacity() and all it's users. The CPU capacity is reduced by > >> RT, DL, IRQ and thermal load avg, not the 'raw' value from the > >> per-cpu variable. > >> > >> TBH I cannot recall what was the argument back then > >> when thermal pressure geometric series was introduced. > >> Maybe to have a better control how fast it raises and decays > >> so other mechanisms in the scheduler will see the change in thermal > >> as not so sharp... (?) > >> > >> > >> Vincent do you remember the motivation to have geometric series > >> in thermal pressure and not use just the 'raw' value from per-cpu? > > > > In order to have thermal pressure synced with other metrics used by > > the scheduler like util/rt/dl_avg. As an example, when thermal > > pressure will decrease because thermal capping is removed, the > > utilization will increase at the same pace as thermal will decrease > > and it will not create some fake spare cycle. util_avg is the average > > expected utilization of the cpu, thermal pressure reflects the average > > stolen capacity for the same averaging time scale but this can be the > > result of a toggle between several OPP > > > > Using current capping is quite volatile to make a decision as it might > > have changed by the time you apply your decision. > > > > So for this scenario, where we want to just align EAS with SchedUtil > frequency decision, which is instantaneous and has 'raw' value > of capping from policy->max, shouldn't we use: > > thermal_pressure = arch_scale_thermal_pressure(cpu_id) Yes you should probably use arch_scale_thermal_pressure(cpu) instead of thermal_load_avg(rq) in this case > > instead of geometric series thermal_pressure signal? > > This would avoid the hassling with idle CPUs and not updated > thermal signal.