Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp1496940pxv; Fri, 2 Jul 2021 05:22:41 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzvxLBzYYtD8o2eECZCN7eXFrTZC9yooGaHkODGriTIILpOAh16Tf3Qq4TpiztW6fbj+R47 X-Received: by 2002:a17:906:c148:: with SMTP id dp8mr4851168ejc.507.1625228561166; Fri, 02 Jul 2021 05:22:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1625228561; cv=none; d=google.com; s=arc-20160816; b=Ux2zQJHKtrLwDSpp37G7iNYQ5iDRHbSi//ic9QCJl859o4nYrpVGrU3kfuTAvEBJRZ 9PZirTKK6iKvYZ1cbe3Yz8kh+udWoLUlzgwudhSlNJoPxQa35QPT3ORZE3s0YBZi6bKq de9muzlEj5uW348yw2QZE92rS787ZdWB8dmDwIAWtp1w986LdRqsJsAEOorZEJWqQMRe 06G7fIWm8beHajjX00t2EjPIzWTxFgtyvHK1Ze1t/yZrLoUba9YmmTF+n9ggqn6WCnU9 tDQOW02/vA69AiZ1Zwgkq40BbSpcKBgGtbJaIM25msEJqGX931JnDovVI3H9HsQQiSTC tm2w== 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=oSTwRgQreABlkbRxnPP4j/qlHGK8vM2Efb6HKlZKq4U=; b=QCCDlheJNNjp7Di8P2f4Mr8slOZS6gHKbe6WTKCrumXc50tjSKbYl8VvTxRMGdEA1U oKs3FNqJTrt0QfM65dRZUfhS0nbqI+Wg4H1y2MW0QMrqJjR1rkMZZbBsJycCG2whcyb5 ylUzUVa//HQRMDAszO6nh2P9zWxMY4/5l+/cuHR7ec2xdE5/dVGp6NMYkE/rdUGsuMnr Ex4bJhHX/VE0m8ISHuAGabvEvlCf/TtcLhoPd5l7uIpta2D8V8RtENpuYBqdJqee6xUm meDvBhPiHmBeQmFKqBfcoMrAff0iJP3ndYkx6/2nM3UkxMlBD6KuaVVHpQI2Df0Y+8Gt eN1A== 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 er9si2937253ejc.420.2021.07.02.05.22.07; Fri, 02 Jul 2021 05:22:41 -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 S232079AbhGBMWf (ORCPT + 99 others); Fri, 2 Jul 2021 08:22:35 -0400 Received: from foss.arm.com ([217.140.110.172]:46518 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232058AbhGBMWf (ORCPT ); Fri, 2 Jul 2021 08:22:35 -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 9E9541FB; Fri, 2 Jul 2021 05:12:47 -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 CC1623F718; Fri, 2 Jul 2021 05:12:45 -0700 (PDT) From: Valentin Schneider To: Qais Yousef , Peter Zijlstra Cc: Xuewen Yan , mingo@redhat.com, juri.lelli@redhat.com, vincent.guittot@linaro.org, dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de, bristot@redhat.com, linux-kernel@vger.kernel.org, patrick.bellasi@matbug.net, qperret@google.com Subject: Re: [PATCH v2] sched/uclamp: Avoid getting unreasonable ucalmp value when rq is idle In-Reply-To: <20210702115421.gcju2vluhof6rp6f@e107158-lin.cambridge.arm.com> References: <20210630141204.8197-1-xuewen.yan94@gmail.com> <20210702115421.gcju2vluhof6rp6f@e107158-lin.cambridge.arm.com> Date: Fri, 02 Jul 2021 13:12:41 +0100 Message-ID: <87wnq87w3q.mognet@arm.com> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/07/21 12:54, Qais Yousef wrote: > sched/uclamp: Ignore max aggregation if rq is idle > > 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 Nit: those values are "intentionally stale" for UCLAMP_MAX, per e496187da710 ("sched/uclamp: Enforce last task's UCLAMP_MAX") for UCLAMP_MIN we'll set uclamp_none(UCLAMP_MIN) == 0 upon dequeueing the last runnable task, which DTRT. > 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 ^^^^^^^^^^^^ Per the above, it's "only" a problem for UCLAMP_MAX. > 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. >