Received: by 2002:a05:7412:8d10:b0:f3:1519:9f41 with SMTP id bj16csp439665rdb; Tue, 5 Dec 2023 09:24:25 -0800 (PST) X-Google-Smtp-Source: AGHT+IHl7mXxlHnjh/ZRLuVs8NKweLjKYaA1YDCafkOeF4f0H6QkJlsA3SSEmg+QRQcX4RJ0u2tm X-Received: by 2002:a17:902:ac85:b0:1cf:c35d:12fc with SMTP id h5-20020a170902ac8500b001cfc35d12fcmr1950677plr.19.1701797065661; Tue, 05 Dec 2023 09:24:25 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1701797065; cv=none; d=google.com; s=arc-20160816; b=h1Z10UJJH7hqFCak+FhTZWN0f7hQribyHRI8vdFWt59AsVThYRi+LmkyaSNLA6xSLE j4OWvO31MCsLv6KT087N7egYT8gZoeGTRm2ECAjo9WeXNJr6hZEE5RErebhG95jZ7rVG XWMqyeo04iT4mAmwezD0v5Ys4MZmUmJ2uI2pewAW8CozsC+8QPCJ3H8DCyOYTv4uAnlc XCLXSBlPH3rQGblwtrWcMLq8pNXPIP5iWfBpvQF8Jlg9OC+fkQlm+gViOay5dTw/M+4A 7ahXo/JvUikENKYzYswajAENrfMWy8stCjsSnoCDo1UXqbYjuHrWbHRBQxqQht+GRpQX 2aUQ== 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 :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id; bh=muNtcocX8TL8McYFZNcYBwUkA/QLVRPrXfyAjmDuFvo=; fh=mKQPqrtRK91ePeu5PwKnPOiALFSQ8ogzt1x2RIvo6IU=; b=LiH0LuTEmFqXW+5AlNkr4tYLuZzddub4RizUNgn2FlHgYxBqKW9LXzHjGH3Z5oWhoN 9uEY0zG+mopu/iWYQthKREpkfzHrL9w1cAkw7Ez69z0hJb+64PLj4vbm41PR/LPlNF+4 JHh7vlMstyrgKuT8KDpdfugAtru//I9jaKVDmrqTKDN2mRzLKsgarlGqJ3ZgiH0pBUKk 15rCtKSdtHMclSnlEQV6TZRNcI/5PnIbv0Ed3BtLG9G5y9lwitDn9x7J0aP1zg6VxXdG uVsMNJxbbNZQAqUeZlcHsWpMzFF4K94T9YOZtf+830Sw8MITct6hUDbXbSzvzV/vAZJ2 jd5g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:1 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 morse.vger.email (morse.vger.email. [2620:137:e000::3:1]) by mx.google.com with ESMTPS id a72-20020a63904b000000b005c65bfc76b7si6212828pge.570.2023.12.05.09.24.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 Dec 2023 09:24:25 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:1 as permitted sender) client-ip=2620:137:e000::3:1; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:1 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by morse.vger.email (Postfix) with ESMTP id AFBC380E709C; Tue, 5 Dec 2023 09:24:16 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at morse.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346018AbjLERX5 (ORCPT + 99 others); Tue, 5 Dec 2023 12:23:57 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51136 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235253AbjLERXw (ORCPT ); Tue, 5 Dec 2023 12:23:52 -0500 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 743331A5 for ; Tue, 5 Dec 2023 09:23:58 -0800 (PST) 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 B5C03139F; Tue, 5 Dec 2023 09:24:44 -0800 (PST) Received: from [10.1.31.59] (e133649.arm.com [10.1.31.59]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 768BF3F5A1; Tue, 5 Dec 2023 09:23:56 -0800 (PST) Message-ID: <7f0bfaa5-22c3-4ed3-bf34-cb7ad6b4c335@arm.com> Date: Tue, 5 Dec 2023 17:23:54 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH 0/6] sched: uclamp sum aggregation To: Vincent Guittot Cc: Qais Yousef , Ingo Molnar , Peter Zijlstra , Dietmar Eggemann , Morten Rasmussen , Lukasz Luba , Christian Loehle , linux-kernel@vger.kernel.org References: <20231203002544.d4zx3oyvjugohh22@airbuntu> <7f1f7dd0-e3b5-4e16-a44e-c08fca567f97@arm.com> Content-Language: en-US From: Hongyan Xia In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-0.8 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on morse.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (morse.vger.email [0.0.0.0]); Tue, 05 Dec 2023 09:24:16 -0800 (PST) On 05/12/2023 16:26, Vincent Guittot wrote: > On Tue, 5 Dec 2023 at 16:19, Hongyan Xia wrote: >> >> On 04/12/2023 16:12, Vincent Guittot wrote: >>> On Mon, 4 Dec 2023 at 02:48, Hongyan Xia wrote: >>>> >>>> [...] >>>> >>>> Other shortcomings are not that critical, but the fact that uclamp_min's >>>> effectiveness is divided by N under max aggregation I think is not >>>> acceptable. >>> >>> Change EAS task placement policy in this case to take into account >>> actual utilization and uclamp_min/max >> >> Thank you. I agree. I want to emphasize this specifically because this >> is exactly what I'm trying to do. The whole series can be rephrased in a >> different way: >> >> - The PELT signal is distorted when uclamp is active. > > Sorry but no it's not >> - Let's consider the [PELT, uclamp_min, uclamp_max] tuple. > > That's what we are already doing with effective_cpu_util. We might > want to improve how we use them in EAS but that's another story than > your proposal It's different. We never catch how we *got* the PELT value. If we wake up a task, what we do now is to have the following: [p->util_avg, p->uclamp_min, p->uclamp_max, target_rq->uclamp_min, target_rq->uclamp_max] But to best understand how big this task really was, we want: [p->util_avg, previous_rq->uclamp_min_back_then, previous_rq->uclamp_max_back_then] Without such information, issues cannot be avoided because we have no idea how big the task really was. Frequency spikes is just one of the symptoms when we mis-interpret how big the task was. >> - Always carrying all three variables is too much, but [PELT, >> clamped(PELT)] is an approximation that works really well. > > As said before. It's a no go for this mix I see your concern. To rephrase this series again, I'm simply arguing that [p->util_avg, previous_uclamp_min, previous_uclamp_max] is better than [p->util_avg, p->uclamp_min, p->uclamp_max, target_rq->uclamp_min, target_rq->uclamp_max] plus the code to mitigate the issues in estimating how big the task is. I anticipate this series to be significantly smaller than the current max aggregation approach plus future code to mitigate the problems, but I'll keep trying to improve it to hopefully address your concerns. >> >> Of course, I'll explore if there's a way to make things less messy. I >> just realized why I didn't do things util_est way but instead directly >> clamping on PELT, it's because util_est boosts util_avg and can't work >> for uclamp_max. I'll keep exploring options. >> >>>> [...]