Received: by 2002:ad5:4acb:0:0:0:0:0 with SMTP id n11csp339979imw; Fri, 15 Jul 2022 04:27:39 -0700 (PDT) X-Google-Smtp-Source: AGRyM1uc/U79jg7MTS5W0F4LB8opcrIR6RsbQ62voF6FfugSIhei5swWCNXOzguSpPzynlC7WwrB X-Received: by 2002:a17:90b:1d87:b0:1f0:6c87:fc8 with SMTP id pf7-20020a17090b1d8700b001f06c870fc8mr14876463pjb.173.1657884459431; Fri, 15 Jul 2022 04:27:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1657884459; cv=none; d=google.com; s=arc-20160816; b=1LOJ7oD4bJ9PzWA+z1pw5SvXAYaT4UqjVmpdgFK5MF8n7TERe21gat9je4yvoUjYuB C/QEUqix529s/ugKaXtW2iQMHJZzlSO+XQD6R+O8WtecESooB356delGrkiZJxbTDaQb /33QxK9Y2Syk3rYqeCAascjc4Tve4OddINutYsR/UbWuf0iyG5MVW1j8S7MCbd1jWOS0 92xuTuCatHzyKFOeQ3Fuucw+4LGQMWhioB9rNpJ3HoiQspVWs3wtdGeKii7FEeSgp23q J3Cbaikc2jTevs/jXqTr6ifSarblBG30HPG7/86OddqBi54pqrebelaVV9VqjWpfnXgd b2Xg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=6LH9jR6wLD9xXK407S5jiY2C60H1KbWZH1T3PXw2xHo=; b=jOsI29HmOcUL3VXuiEfGedBLLuOVLdiLsBqi2iKrE7nIozl9y+5dv3nClE85VlbLaD /TWOxMzQ7IFzLBhkBaJSFlhwpDq54bfNQbiMJ/kZYAt4ffJRdyzyIhbQ8tpqNOxaWyIP SdU5X6ks9DXHTmWRpSuccFdJ/0QXPPRza6Kg0gGMWkebr8zVLpVn8O5EKg2c1oCC0JlA +OWpSaHX8HdFxhlggAbgEAi7qxNrYIu7CWhlfI899AXzrzd5q04VYKHYw6dKSbw6A0r8 RGvlpl5uUduxqB2g8FWLJQNLGXDo6I2yOE+DCeCFvqKI7sYQ1MzK1IzNpYZyTK6kCYR7 vjHw== 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 j3-20020a170903028300b00163e1591f90si5996890plr.24.2022.07.15.04.27.24; Fri, 15 Jul 2022 04:27:39 -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 S231197AbiGOKhn (ORCPT + 99 others); Fri, 15 Jul 2022 06:37:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40080 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229436AbiGOKhm (ORCPT ); Fri, 15 Jul 2022 06:37:42 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 5CE91753BB for ; Fri, 15 Jul 2022 03:37:41 -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 8AC9B1474; Fri, 15 Jul 2022 03:37:41 -0700 (PDT) Received: from wubuntu (unknown [10.57.87.59]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id B8BA73F792; Fri, 15 Jul 2022 03:37:39 -0700 (PDT) Date: Fri, 15 Jul 2022 11:37:38 +0100 From: Qais Yousef To: Vincent Guittot Cc: Ingo Molnar , "Peter Zijlstra (Intel)" , Dietmar Eggemann , linux-kernel@vger.kernel.org, Xuewen Yan , Wei Wang , Jonathan JMChen , Hank , Lukasz Luba Subject: Re: [PATCH 1/7] sched/uclamp: Fix relationship between uclamp and migration margin Message-ID: <20220715103738.ufqv2nhkivlhzy7v@wubuntu> References: <20220629194632.1117723-1-qais.yousef@arm.com> <20220629194632.1117723-2-qais.yousef@arm.com> <20220712102334.6nwkbkilmmup4h4u@wubuntu> <20220712142013.j6fy77yejupvllah@wubuntu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI, 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 On 07/13/22 14:39, Vincent Guittot wrote: [...] > > > That's why I have mentioned that I have thermal pressure and irq in > > > mind. I'm speaking about performance level but not about bandwidth and > > > time sharing. > > > > irq pressure has no impact on the cpu's ability to get any OPP, no? It purely > > reduces the bandwidth availability for CFS tasks AFAIU. So the task's ability > > to achieve a performance level has no correlation with irq pressure IMO. Unless > > I missed something. > > The way irq is accounted in pelt might impact the result. TBH, i > haven't looked in details what would be the impact I can't see how irq can impact what performance level we can achieve on any CPU. It should just impact bandwidth? [...] > > > more concerned by the thermal pressure as I mentioned previously. As > > > an example the thermal pressure reflects the impact on the performance > > > while task is running. > > > > Like we discussed on that RT email thread. If you have a 1024 task, tiny > > thermal pressure will make it look like it won't fit anywhere. > > maybe another big core without pressure. Otherwise if the task can Isn't thermal pressure per perf domain? > accept a lower compute capacity why not setting uclamp_min to a lower > value like 900 Well if the system has lost its top 10% and you're still running as fast as the system can possibly do, what better can you do? I can't see how comparing uclamp with thermal pressure will help. In feec() we pick the highest spare capacity CPU. So if the bigs were split into 1 per perf domain and truly one of them can become severely throttled while the other isn't as you're trying to say, then this distribution will pick the highest spare capacity one. fits_capacity() just says this CPU is a candidate that we can consider. [...] > > > TaskA usually runs 4 ms every 8ms but wants to ensure a running time > > > around 5ms. Task A asks for a uclamp_min of 768. > > > medium cpu capacity_orig is 800 but runs at half its max freq because > > > of thermal mitigation then your task will runs more than 8ms > > > > If thermal pressure is 50%, then capacity_of() is 400. A 50% task will have > > util_avg of 512, which is much larger than 0.8 * 400. So this is dealt with > > already in this code, no? > > May be my example is not perfect but apply a mitigation of 20% and you > fall in the case capacity_orig_of(medium) = 800 capacity_of(medium) = 800 * 0.8 - sum_of_(irq, rt) pressure :: <= 640 migration_margin * capacity_of(medium) = 0.8 * 640 = 512 === p->util_avg So this task will struggle still to run on the medium even under 20% pressure. I can see your point for sure that we could have scenarios where we should pick a bigger CPU. But my counter point is that if there's a meaningful thermal pressure we are screwed already and uclamp can't save the day. I'll repeat my question, how would you encode the relationship? Consider these scenarios: capaity_orig_of(little) = 400 capaity_orig_of(medium) = 800 capaity_orig_of(big) = 1024 p0->util_avg = 300 p0->uclamp_min = 800 p1->util_avg = 300 p1->uclamp_min = 1024 When there's 10% thermal pressure on all CPUs. Does p1 fit on big still? Fit here means the big is a viable candidate from uclamp point of view. How would you define the relationship so that p0 will not fit the medium, but p1 still fits the big. What happens when thermal pressure is 1%? Should p0 still fit on the medium then? As Lukasz highlighted in other email threads, the decay of thermal pressure signal has a very long tail. Thanks! -- Qais Yousef