Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp367524pxv; Wed, 30 Jun 2021 07:25:32 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz+ENGr+K/Z4r64fdEqQPoNdKHN1Ro+G5pKGi5+fAAST4lOxQ3brP3OPBF0m/fkh+lxO5+S X-Received: by 2002:a92:d3cb:: with SMTP id c11mr25978028ilh.126.1625063132661; Wed, 30 Jun 2021 07:25:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1625063132; cv=none; d=google.com; s=arc-20160816; b=z+lhGHXR7OC/8WVgTSY32ZOred4+AcQKm+WAvW8FxLTNAK0RzaQSIpenO6QRjgRhTs XSwpqk2OK2VrxV/jZAjWAsS1yAxkhAPw9/Oarfg3vWmP6ZdeifVp4t52oB0n0UYgLIeU Zret7yo0gp4asZ3mvkyaExnfV8fpkX+5+i2TaxYZ9FEfK06v5d80r29J0sDDlGSUxlHu 9KK75DzQLJGQDZSsjOgEOFOF1jMZqM4iC47hFDs4mScWTa+04fUVXQKIDdaQvvozCBq3 oQ1PrCHg3eWVjw8dS8dKLgIUCedvqNnsB40MrdeTQPC4/8fqzZcUS+yXuFCjVrJcJhS+ qdvQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from; bh=1ikbJTsKt+gmH4zAjzvCdwSDlGjceichaetho3mAlYE=; b=ajGFrBLB5DHFvhmU3KuL4afmfiHtMHcCZt2opJSbsGzn/YTCeAUwAMwKBQ7iJyGi5I 7yAeO5iJLb2nH5riIQQ9CnMMAjpBgngyOhgtMR4kaaVQceAtGKIrV0ZhtO3ZJPWZgE6h +ODFe/NAXPFNCtW45p90cqxv9hQHObj5vB1/xznglG3r0+aj7xJ8dRcrHZvZ2EVyR6XI yu7t3A2WJmuWJ+7TYA6HpoPpfEgICPs1HG5IDKPTycbAGp3OV/5r5IMsNHFo3sd1UyDM 98ZctjQZO2UtGficyh0X4XqBumeSxeKjBfb4ioEKIYoxg9G6OykWthGPlJChCmnp5NcK jSTg== 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 ay42si4031185jab.110.2021.06.30.07.25.19; Wed, 30 Jun 2021 07:25:32 -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 S235027AbhF3O1S (ORCPT + 99 others); Wed, 30 Jun 2021 10:27:18 -0400 Received: from foss.arm.com ([217.140.110.172]:39576 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234913AbhF3O1R (ORCPT ); Wed, 30 Jun 2021 10:27:17 -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 BA1C16D; Wed, 30 Jun 2021 07:24:48 -0700 (PDT) Received: from e113632-lin (e113632-lin.cambridge.arm.com [10.1.194.46]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id F0AEC3F718; Wed, 30 Jun 2021 07:24:46 -0700 (PDT) From: Valentin Schneider To: Xuewen Yan , mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com, vincent.guittot@linaro.org, dietmar.eggemann@arm.com Cc: rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de, bristot@redhat.com, linux-kernel@vger.kernel.org, patrick.bellasi@matbug.net, qais.yousef@arm.com, qperret@google.com Subject: Re: [PATCH v2] sched/uclamp: Avoid getting unreasonable ucalmp value when rq is idle In-Reply-To: <20210630141204.8197-1-xuewen.yan94@gmail.com> References: <20210630141204.8197-1-xuewen.yan94@gmail.com> Date: Wed, 30 Jun 2021 15:24:42 +0100 Message-ID: <87a6n78m6t.mognet@arm.com> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On the subject: s/ucalmp/uclamp/ On 30/06/21 22:12, Xuewen Yan wrote: > From: Xuewen Yan > > Now in uclamp_rq_util_with(), when the task != NULL, the uclamp_max as following: > uc_rq_max = rq->uclamp[UCLAMP_MAX].value; > uc_eff_max = uclamp_eff_value(p, UCLAMP_MAX); > uclamp_max = max{uc_rq_max, uc_eff_max}; > > Consider the following scenario: > (1)the rq is idle, the uc_rq_max is last runnable task's UCLAMP_MAX; > (2)the p's uc_eff_max < uc_rq_max. > > As a result, the uclamp_max = uc_rq_max instead of uc_eff_max, it is unreasonable. > > The scenario often happens in find_energy_efficient_cpu(), when the task has smaller UCLAMP_MAX. > > When rq has UCLAMP_FLAG_IDLE flag, enqueuing the task will lift UCLAMP_FLAG_IDLE > and set the rq clamp as the task's via uclamp_idle_reset(). It doesn't need > to read the rq clamp. And it can also avoid the problems described above. > > Fixes: 9d20ad7dfc9a ("sched/uclamp: Add uclamp_util_with()") > > Signed-off-by: Xuewen Yan > Thanks! Reviewed-by: Valentin Schneider