Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp5621429pxj; Wed, 23 Jun 2021 05:35:35 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzvcCAdeKIDzi9xZZgJ+JrQIYJAb0xrM2HBdAaQGCxpXaVkBXgT23NCN1bWzHkfGYttWtqz X-Received: by 2002:a02:c997:: with SMTP id b23mr6051277jap.64.1624451735629; Wed, 23 Jun 2021 05:35:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1624451735; cv=none; d=google.com; s=arc-20160816; b=DUTx/0PyGNTI473qJyTt7BvirlCtiEdqb7GAuO68DNkxzXevQuWdTYnjzrRRR5oVTW OSsuJOHmjW2qwE/i88nx8hCsxHWmQ6G/cUkFyxbqwIgTmt46qnC+E7ip4gw+9JHa4PvQ 5Trfya86RMCuI+OqwJ3OASuZNOinecmLFZ83hvLlAdj32zka9Oz2sAF2QzenLON/b/rx f8WEEgnncHl9b89icDfhtUhQFm7ZsABFGvB5b2uuHm3jYUho7wPKhmgQeQMxrzfQ2dSN f3OWtXd9Q9Y6Lr5MPjWzldUa16dEkxpMv/+1e+VkdWNAgGuj25w8bs8kZW2edRbUO6tB /MCQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:from:subject:references:mime-version :message-id:in-reply-to:date:dkim-signature; bh=T0nSoJ5wzCyMprwr8b/+7hv8RW3/0jpCRYtsGO6gL4Q=; b=xS42ZwjOYzo3/6sX/8V3zS4JOQpGj1CQR7DF2s5s+8gSHF784STP+XBSJvjVGLdcie OG/SFlkuXYiC9c8e7Ai62dwu3eYYXONMxEz0h9E1D7b2VxfRSb0K/h3bO8zOAOX0iKte NKZgax+i/+Jzrn2enO7/KdZaPcf9r25+N9koOZcg372bMXkIY/0LILHM17wn2RCAu15B halo/EhIkqoAahSG/Fro/nkTBUm7m/0jjfL4fhaegNqWn5O99rXXzIHdAVkyaXrgrXP/ vix+vEh138029OxpwDnPcFlGN26zyQaOJxjUhPGcKzdHxFwyEjaGUPc/h6hpEp7cf7F0 efUA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=TByi0SbB; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id q11si22300372ilo.33.2021.06.23.05.35.23; Wed, 23 Jun 2021 05:35:35 -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=@google.com header.s=20161025 header.b=TByi0SbB; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230274AbhFWMhH (ORCPT + 99 others); Wed, 23 Jun 2021 08:37:07 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33368 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230170AbhFWMhG (ORCPT ); Wed, 23 Jun 2021 08:37:06 -0400 Received: from mail-wr1-x44a.google.com (mail-wr1-x44a.google.com [IPv6:2a00:1450:4864:20::44a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F0578C061756 for ; Wed, 23 Jun 2021 05:34:48 -0700 (PDT) Received: by mail-wr1-x44a.google.com with SMTP id h17-20020adff4d10000b029011a7b7961dbso1013785wrp.15 for ; Wed, 23 Jun 2021 05:34:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:in-reply-to:message-id:mime-version:references:subject:from:to :cc; bh=T0nSoJ5wzCyMprwr8b/+7hv8RW3/0jpCRYtsGO6gL4Q=; b=TByi0SbBnqTnjMPgblA791r9/PtSoxty8K5P02++XsSzLWpYVq4k1HpUUmsPdxIAB5 Y6GG8enviW5savGoi0XIfwyNwb247sON2Q8P5r7UZNMr35OYxYFC5eDb8w9Yd6WIFkTf LdGecknpLWj+Q/t7074wAfwMnybPj7Is4MGT8DJM62BdfiAu3Ybyqt9yYuFlu55KOaxt dVm8mbWBZGXYZdog4XKJqQSN/YAkT7irkn7OiMmE/jq7x6RGFcXiEdp2J4fhTxckha+D uECYcftFoBYJsef/vIFJ5nOh0xwnjrRLQ4HUOS2rq7HOPN3tPIwJCC5S5tgruA7J0bqB ruZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:in-reply-to:message-id:mime-version :references:subject:from:to:cc; bh=T0nSoJ5wzCyMprwr8b/+7hv8RW3/0jpCRYtsGO6gL4Q=; b=eAuW+woYw+D6rYxJ81JJStfTOy1Fw+wSLOpJExq/5gFGyhRO0QPmQzRSySY9KXw/4/ 80DUaUHGfzIBdVOW8dDo9eGvwfGfa3cSI6D2d2rOpKuToM/RU0JUH+0hHmpV8FnDKbdw 8mp9Imr92YFZotemaq4jK1oS3R7EPXtPjTuTQIB0JRNHhZc1cukOaXJsyXnjM0mAePAA ny4X8CUTCeeiOnHqAcmmX1/c7/gLcahN7JmK51uLRcMFmofOcYAdKOBctPW+XN1hCQlz HdoOvB3vUOo/NzxyYfu8YK6dVAxguafR+r4XOBAq0bhbMvSYaLZH2g+SzjqA32arx1Y3 AAGA== X-Gm-Message-State: AOAM530FjD2wRFsHtZQhRft17mDLLyEy0blVmE9F6amuGjyNmfgEr67V otjOY9HlxoKgR8RYlOyU/P/tB7f5UQWX X-Received: from r2d2-qp.c.googlers.com ([fda3:e722:ac3:cc00:28:9cb1:c0a8:1652]) (user=qperret job=sendgmr) by 2002:a05:6000:8b:: with SMTP id m11mr11018582wrx.22.1624451687474; Wed, 23 Jun 2021 05:34:47 -0700 (PDT) Date: Wed, 23 Jun 2021 12:34:39 +0000 In-Reply-To: <20210623123441.592348-1-qperret@google.com> Message-Id: <20210623123441.592348-2-qperret@google.com> Mime-Version: 1.0 References: <20210623123441.592348-1-qperret@google.com> X-Mailer: git-send-email 2.32.0.288.g62a8d224e6-goog Subject: [PATCH v3 1/3] sched: Fix UCLAMP_FLAG_IDLE setting From: Quentin Perret To: mingo@redhat.com, peterz@infradead.org, vincent.guittot@linaro.org, dietmar.eggemann@arm.com, qais.yousef@arm.com, rickyiu@google.com, wvw@google.com, patrick.bellasi@matbug.net, xuewen.yan94@gmail.com Cc: linux-kernel@vger.kernel.org, kernel-team@android.com, qperret@google.com Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The UCLAMP_FLAG_IDLE flag is set on a runqueue when dequeueing the last active task to maintain the last uclamp.max and prevent blocked util from suddenly becoming visible. However, there is an asymmetry in how the flag is set and cleared which can lead to having the flag set whilst there are active tasks on the rq. Specifically, the flag is cleared in the uclamp_rq_inc() path, which is called at enqueue time, but set in uclamp_rq_dec_id() which is called both when dequeueing a task _and_ in the update_uclamp_active() path. As a result, when both uclamp_rq_{dec,ind}_id() are called from update_uclamp_active(), the flag ends up being set but not cleared, hence leaving the runqueue in a broken state. Fix this by clearing the flag in uclamp_idle_reset() which is also called in both paths to ensure things remain symmetrical. Fixes: e496187da710 ("sched/uclamp: Enforce last task's UCLAMP_MAX") Reported-by: Rick Yiu Reviewed-by: Qais Yousef Signed-off-by: Quentin Perret --- kernel/sched/core.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/kernel/sched/core.c b/kernel/sched/core.c index 4ca80df205ce..e514a093a0ba 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -980,6 +980,7 @@ static inline void uclamp_idle_reset(struct rq *rq, enum uclamp_id clamp_id, if (!(rq->uclamp_flags & UCLAMP_FLAG_IDLE)) return; + rq->uclamp_flags &= ~UCLAMP_FLAG_IDLE; WRITE_ONCE(rq->uclamp[clamp_id].value, clamp_value); } @@ -1252,10 +1253,6 @@ static inline void uclamp_rq_inc(struct rq *rq, struct task_struct *p) for_each_clamp_id(clamp_id) uclamp_rq_inc_id(rq, p, clamp_id); - - /* Reset clamp idle holding when there is one RUNNABLE task */ - if (rq->uclamp_flags & UCLAMP_FLAG_IDLE) - rq->uclamp_flags &= ~UCLAMP_FLAG_IDLE; } static inline void uclamp_rq_dec(struct rq *rq, struct task_struct *p) -- 2.32.0.288.g62a8d224e6-goog