Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp3275203pxj; Mon, 7 Jun 2021 06:50:33 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwvSAkwlZnl6R87sqfb6UxUSFKQ+31WUZjrblYo67BXTlH+ubwVZUuePspcFC1UsnLRrUII X-Received: by 2002:a05:6402:1a25:: with SMTP id be5mr19847970edb.369.1623073833055; Mon, 07 Jun 2021 06:50:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1623073833; cv=none; d=google.com; s=arc-20160816; b=chLakxH73yeKoqDlVDLOVnYdj6xt+n0cBKzo1eL+Siry8tEO63WusHvuU7uHwCxNZM 6Hv5I3YK3c/CP4wJp85AXssCse1U/K5wcj6sjyIpDExYXsgUnDp10Wpgt/vLJUsmi8r/ BlovIcpVBp40AEwnXLeURO9KUBhEpkvg3dnUkF3m7Hy9ZTJOzUg0Qv6zyBgicGcY4zrO H0as19D4KiNpRSyM89LsP8hecE7/uij8h+aSfb1K/FOZsvBRZs7cQXlx5n8kn3zdOWeE 5TtQHg2u6k9viWnZQeX+zkrdd4ODIRQcZevEEMmCIT4sduhv/zXtD+iQi9qGMLl8vIlA iDjw== 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-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=sYluoVYkyS5bN3n6L3vbrR5mpCH4S17v3CpGT0YoSNY=; b=zk5Vx9n4/jjeI4QHCYG5APusrTKffYAYtfMcX0MshGL3xQ9QNoIVxGWnMWM/F4SlM+ boTYVU6Ndfa37Mw2z5868nV2n6xAvHOmpEKuTZc+6of+H9X0Klz4yvkRS3KyI52weIql zc40otka+j8muvNm+Ev46RXq3WE2MuvyaRIn35oxRaqN4CSZtuazSzkfQyYKhQM1iYZC 9uRgdiNJOHh0kX15Pjvz+GiQAp2COwyCLBYBJncsxO/8VsTmZQ/nerty5Paenp3P6707 Ewi8iPmJV/y9cY2fY40b2o+U++sRrZJ6V4VinggEBXSnzZWfolY+uaNSVtsUpStIeAy4 syrg== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id c7si1639103ejc.291.2021.06.07.06.50.10; Mon, 07 Jun 2021 06:50:33 -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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230266AbhFGNu6 (ORCPT + 99 others); Mon, 7 Jun 2021 09:50:58 -0400 Received: from foss.arm.com ([217.140.110.172]:33896 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230177AbhFGNu6 (ORCPT ); Mon, 7 Jun 2021 09:50:58 -0400 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 99802143D; Mon, 7 Jun 2021 06:49:06 -0700 (PDT) Received: from e107158-lin.cambridge.arm.com (e107158-lin.cambridge.arm.com [10.1.195.57]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 9B19F3F694; Mon, 7 Jun 2021 06:49:04 -0700 (PDT) Date: Mon, 7 Jun 2021 14:49:02 +0100 From: Qais Yousef To: Xuewen Yan Cc: Quentin Perret , Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Benjamin Segall , Mel Gorman , Daniel Bristot de Oliveira , linux-kernel , Chunyan Zhang , Ryan Y , Patrick Bellasi , tj@kernel.org Subject: Re: [PATCH] sched/uclamp: Avoid setting cpu.uclamp.min bigger than cpu.uclamp.max Message-ID: <20210607134902.nlgvqtzj35rhjg7x@e107158-lin.cambridge.arm.com> References: <20210602123803.15738-1-xuewen.yan94@gmail.com> <20210604160839.2op4ak75vle3gmt3@e107158-lin.cambridge.arm.com> <20210605114908.mqfsip5pskamls6k@e107158-lin.cambridge.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 06/05/21 21:24, Xuewen Yan wrote: > Hi Qais > > On Sat, Jun 5, 2021 at 7:49 PM Qais Yousef wrote: > > > > > > > In addition,In your patch: > > > 6938840392c89 ("sched/uclamp: Fix wrong implementation of cpu.uclamp.min") > > > https://lkml.kernel.org/r/20210510145032.1934078-2-qais.yousef@arm.com > > > > > > + switch (clamp_id) { > > > + case UCLAMP_MIN: { > > > + struct uclamp_se uc_min = task_group(p)->uclamp[clamp_id]; > > > + if (uc_req.value < uc_min.value) > > > + return uc_min; > > > + break; > > > > > > When the clamp_id = UCLAMP_MIN, why not judge the uc_req.value is > > > bigger than task_group(p)->uclamp[UCLAMP_MAX] ? > > > > Because of the requirement I pointed you to in cgroup-v2.rst. We must allow any > > value to be requested. > > > > Ultimately if we had > > > > cpu.uclamp.min = 80 > > cpu.uclamp.max = 50 > > > > then we want to remember the original request but make sure the effective value > > is capped. > > > > For the user in the future modifies the values such that > > > > cpu.uclamp.max = max > > > > Then we want to remember cpu.uclamp.min = 80 and apply it since now the > > cpu.uclamp.max was relaxed to allow the boost value. > > > > > Because when the p->uclamp_req[UCLAMP_MIN] > task_group(p)->uclamp[UCLAMP_MAX], > > > the patch can not clamp the p->uclamp_req[UCLAMP_MIN/MAX] into > > > [ task_group(p)->uclamp[UCLAMP_MAX], task_group(p)->uclamp[UCLAMP_MAX] ]. > > > > > > Is it necessary to fix it here? > > > > Nope. We must allow any combination values to be accepted and remember them so > > if one changes we ensure the new effective value is updated accordingly. > > This is how cgroups API works. > > Sorry. I may not have expressed it clearly. In your patch (which has > not yet merged into the mainline): > > 6938840392c89 ("sched/uclamp: Fix wrong implementation of cpu.uclamp.min") > https://lkml.kernel.org/r/20210510145032.1934078-2-qais.yousef@arm.com > > This patch will not affect p->uclamp_req, but consider the following situation: > > tg->cpu.uclamp.min = 0 > tg->cpu.uclamp.max = 50% > > p->uclamp_req[UCLAMP_MIN] = 60% > p->uclamp_req[UCLAMP_MIN] = 80% > > The function call process is as follows: > uclamp_eff_value() -> uclamp_eff_get() ->uclamp_tg_restrict() > > with your patch, the result is: > > p->effective_uclamp_min = 60% > p->effective_uclamp_max = 50% > > It would not affect the uclamp_task_util(p), but affect the rq: > when p enqueued: > rq->uclamp[UCLAMP_MIN] = 60% > rq->uclamp[UCLAMP_MIN] = 50% > > futher more, in uclamp_rq_util_with() { > ... > > min_util = READ_ONCE(rq->uclamp[UCLAMP_MIN].value); //60% > max_util = READ_ONCE(rq->uclamp[UCLAMP_MAX].value);//50% > ... > if (unlikely(min_util >= max_util)) > return min_util; > > return clamp(util, min_util, max_util); > ... > } > as a result, it would return 60%. Looking at this again now, I better understand what you were trying to say. I got confused that you were still arguing about cgroup inverted cpu.uclamp.min/max, but you're actually talking about something else. It would be a lot easier to not cross talk threads and reply to my patch directly with this remark. Anyways, still well spotted! What you're saying is we need something like the patch below to ensure that the *task request* is within tg uclamp range, right? The worry is that the task's uclamp_min is higher than the tg's uclamp_min, so we end up with the inversion because of that which will not be corrected later. Hmm I need to think a bit more about this.. Cheers -- Qais Yousef --->8--- diff --git a/kernel/sched/core.c b/kernel/sched/core.c index 9e9a5be35cde..e867813b9d5e 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -1405,6 +1405,7 @@ uclamp_tg_restrict(struct task_struct *p, enum uclamp_id clamp_id) { struct uclamp_se uc_req = p->uclamp_req[clamp_id]; #ifdef CONFIG_UCLAMP_TASK_GROUP + unsigned long uc_min, uc_max, val; /* * Tasks in autogroups or root task group will be @@ -1415,23 +1416,10 @@ uclamp_tg_restrict(struct task_struct *p, enum uclamp_id clamp_id) if (task_group(p) == &root_task_group) return uc_req; - switch (clamp_id) { - case UCLAMP_MIN: { - struct uclamp_se uc_min = task_group(p)->uclamp[clamp_id]; - if (uc_req.value < uc_min.value) - return uc_min; - break; - } - case UCLAMP_MAX: { - struct uclamp_se uc_max = task_group(p)->uclamp[clamp_id]; - if (uc_req.value > uc_max.value) - return uc_max; - break; - } - default: - WARN_ON_ONCE(1); - break; - } + uc_min = task_group(p)->uclamp[UCLAMP_MIN].value; + uc_max = task_group(p)->uclamp[UCLAMP_MAX].value; + val = uc_req.value; + uc_req.value = clamp(val, uc_min, uc_max); #endif return uc_req;