Received: by 2002:a05:6a10:1287:0:0:0:0 with SMTP id d7csp3854391pxv; Mon, 19 Jul 2021 10:19:01 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwF6hhqU1S9UpeXiYlMlFEGAwxmKYTwnsVM9pBktNEVH9YENjV0f07iJYVyT2yR4yfHfkVh X-Received: by 2002:a05:6402:1849:: with SMTP id v9mr34762598edy.108.1626715140873; Mon, 19 Jul 2021 10:19:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1626715140; cv=none; d=google.com; s=arc-20160816; b=qUvcBFBQyTL5ylrrDKQbbQJFYSIb+jjIag9F8CNODAwh+93mTUzrANnCgrenRZ4/x/ wTEYRu5obmvpCh1J03NkhtJoFQEbzUy8etDP2isHDOXa89pB1UWtN9czqRQpUNJ/jkzk +wRxu6PhFBKFItfXI/Ot9z6mTkxP4nU8jV/uyE6hSKUtTbnk0jt8kMWdJOnTctVHXVG0 pYG0OCXIum4gBjXmMYdnyej6wlvc4zvsS7CnipWzSDB5EMDVDHhKS/Yn+rzck2hju47I 1lz9YhJiAfS3Azh/eUD0uibIq3+QCayC7wnnwNEoub0h1LtdBqTvBxu2Le23ie0aoy+T +06A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=2EYjucec7Y4y78+AJIM/miw6OKAmJ6Hx1UhgRphXdMU=; b=T7W+FxtQUpv4XpzwurArSHVWEny9W/m4AQYR7U4zX5YUJV5yHd25u97Z5cZOKmJGHt TUDCYxvLjP8tVB7A9yYrlJB3FaaUEcRL/52/bEuWxmZAoUlr+qMOLLKtv/f1Ia0/ADWq K7Klt7O3fNCKARZsbBOeReCmHU7zeGTD3bsqbbrcJ2V3jaUDCGRpgDUkVUGjB/dB2KEK G9Vbt4J+MecmAgmIGOfrn05CVBLnMl+51iYp1NO+HXqDYiiiErTbMVkLNhoaTxGjI2Ed 3a5YKjjUXTAAkaFl/ulH2YFMkekY+2uwzpguPVLoe8lzoNHwUbFPWxR7gc7wsDR7q96M bJ3g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=R6RDhbR3; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id h18si13136834eds.154.2021.07.19.10.18.38; Mon, 19 Jul 2021 10:19:00 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=R6RDhbR3; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1355629AbhGSQg1 (ORCPT + 99 others); Mon, 19 Jul 2021 12:36:27 -0400 Received: from mail.kernel.org ([198.145.29.99]:38164 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1348078AbhGSPYd (ORCPT ); Mon, 19 Jul 2021 11:24:33 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 8BC6C61417; Mon, 19 Jul 2021 16:01:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1626710486; bh=5seagCm6Ve4VniNFFV5xW3qMx/jh+v5Yg6lXa6SkrnQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=R6RDhbR3CfHx3QWAF7uAfE7ijf5Cu6b9FnfQ+PqMRew6RVG9qeOqtN86cYlT1AT7a tBmzkOBhpzSXksu570hZf34qUHUq1eknPlXUY5PLFmk2n5bH5Xh7pwBizm0AticGCI k1C/s79DGzm78ZqGxre9uTvVXjrGRi41B2uwQAFg= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Xuewen Yan , "Peter Zijlstra (Intel)" , Valentin Schneider , Qais Yousef , Sasha Levin Subject: [PATCH 5.10 236/243] sched/uclamp: Ignore max aggregation if rq is idle Date: Mon, 19 Jul 2021 16:54:25 +0200 Message-Id: <20210719144948.536532588@linuxfoundation.org> X-Mailer: git-send-email 2.32.0 In-Reply-To: <20210719144940.904087935@linuxfoundation.org> References: <20210719144940.904087935@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Xuewen Yan [ Upstream commit 3e1493f46390618ea78607cb30c58fc19e2a5035 ] When a task wakes up on an idle rq, uclamp_rq_util_with() would max aggregate with rq value. But since there is no task enqueued yet, the values are stale based on the last task that was running. When the new task actually wakes up and enqueued, then the rq uclamp values should reflect that of the newly woken up task effective uclamp values. This is a problem particularly for uclamp_max because it default to 1024. If a task p with uclamp_max = 512 wakes up, then max aggregation would ignore the capping that should apply when this task is enqueued, which is wrong. Fix that by ignoring max aggregation if the rq is idle since in that case the effective uclamp value of the rq will be the ones of the task that will wake up. Fixes: 9d20ad7dfc9a ("sched/uclamp: Add uclamp_util_with()") Signed-off-by: Xuewen Yan Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Valentin Schneider [qias: Changelog] Reviewed-by: Qais Yousef Link: https://lore.kernel.org/r/20210630141204.8197-1-xuewen.yan94@gmail.com Signed-off-by: Sasha Levin --- kernel/sched/sched.h | 21 ++++++++++++++------- 1 file changed, 14 insertions(+), 7 deletions(-) diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h index fdebfcbdfca9..39112ac7ab34 100644 --- a/kernel/sched/sched.h +++ b/kernel/sched/sched.h @@ -2422,20 +2422,27 @@ static __always_inline unsigned long uclamp_rq_util_with(struct rq *rq, unsigned long util, struct task_struct *p) { - unsigned long min_util; - unsigned long max_util; + unsigned long min_util = 0; + unsigned long max_util = 0; if (!static_branch_likely(&sched_uclamp_used)) return util; - min_util = READ_ONCE(rq->uclamp[UCLAMP_MIN].value); - max_util = READ_ONCE(rq->uclamp[UCLAMP_MAX].value); - if (p) { - min_util = max(min_util, uclamp_eff_value(p, UCLAMP_MIN)); - max_util = max(max_util, uclamp_eff_value(p, UCLAMP_MAX)); + min_util = uclamp_eff_value(p, UCLAMP_MIN); + max_util = uclamp_eff_value(p, UCLAMP_MAX); + + /* + * Ignore last runnable task's max clamp, as this task will + * reset it. Similarly, no need to read the rq's min clamp. + */ + if (rq->uclamp_flags & UCLAMP_FLAG_IDLE) + goto out; } + min_util = max_t(unsigned long, min_util, READ_ONCE(rq->uclamp[UCLAMP_MIN].value)); + max_util = max_t(unsigned long, max_util, READ_ONCE(rq->uclamp[UCLAMP_MAX].value)); +out: /* * Since CPU's {min,max}_util clamps are MAX aggregated considering * RUNNABLE tasks with _different_ clamps, we can end up with an -- 2.30.2