Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp3061836pxb; Fri, 12 Feb 2021 08:16:39 -0800 (PST) X-Google-Smtp-Source: ABdhPJweDuDNuhpRe08dYy1HqUqgFCxkJbCn4AmlN2i/WYpqzgKtTRnHPfP/u3AiTtcUID8798Yj X-Received: by 2002:aa7:d817:: with SMTP id v23mr4073264edq.192.1613146599013; Fri, 12 Feb 2021 08:16:39 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1613146599; cv=none; d=google.com; s=arc-20160816; b=A7D/2AIGxtt4Ch4VPKyQk2TkndOtsrd1UowIo80iTAelVp/znuD84yTppn16boubt0 UQ3ozYtmRCD4AsI4UP0+lSCdtH0LErlWSFOSfvOXZvnzJqi23tnXUeDv82dSMwSWjw2W XXid8ZMHKX9JhaewZ2MB98OuFIMYBYPMSp7QbNUIhqfQsMLo9+b1n12cFIyozvUKE4/B WW9OB+XjtllKKN9qFc8Il5FhQhNNqftuGaULjw/8snGfSqZ3qEwYH8SZBORqmzf6KJEW AsQ8qO2Z6yopDSrMyvpeO6brpWDlk69LKWbbDoWVCXoQxYBv2FrzaPNOou/sI2MzCgK6 zr6g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version; bh=lXNUtlsEhBTv3Qbo5ZsDYSNl4IO2zUHe9HmhCN3Jg7I=; b=KfHPfC519H5au85t7ejXPop6WpLCgsLuIRy/tG9Sdb0t4JwNQLRKcHdy/5jtm/CLH1 vI3eFAU2FoNyU4RC5qC0f+THCI7M6p+F+5u2OhhkfPWYrmTWC3zhjmoHNYs300PvxKXZ EseVoVWmwe6JsYmRHv214eh3q5maaRWS3afx0bKUvq02PIpLqID7Kl2kUKczzGC7b0pW TdiTQhmoBR3kQB2T+Ke0TUfKu/n+FApPe2Gpw9Ud5k8aKbKh7hLSbSDPwIj99kWgkcz4 Mp/CZv6LlleXAPykmZ/mQXitZx6cbP7WXY8smMvrjYI7sqortkcBRwm8t/Pc51eNp99r zXxg== 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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id d24si6851649edy.17.2021.02.12.08.16.15; Fri, 12 Feb 2021 08:16:39 -0800 (PST) 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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231532AbhBLQPA (ORCPT + 99 others); Fri, 12 Feb 2021 11:15:00 -0500 Received: from mail-oi1-f181.google.com ([209.85.167.181]:46375 "EHLO mail-oi1-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229611AbhBLQO7 (ORCPT ); Fri, 12 Feb 2021 11:14:59 -0500 Received: by mail-oi1-f181.google.com with SMTP id f3so98926oiw.13; Fri, 12 Feb 2021 08:14:40 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lXNUtlsEhBTv3Qbo5ZsDYSNl4IO2zUHe9HmhCN3Jg7I=; b=Cf0oLZOXRkFG1LpB0GovV7bcZR1+TimOsEErnW7xrjG5NZe5CtOX3RFgv+YXrT0FaR lv4ucuhE2sydTPz8M6jq6uUpKjsik1nqVR7WRHDyYTJCiWqkFuKDgSmalyqRr+G7UmDF dWqYorHN5I8MXqF6vnWQzcWX7viFE9L+dcuvTmWVuJKpDD5VD1zT/WMdTq8ADP/0nT8X /JjbXz3mGQKDLyP5U51jbbEw+C3XJbU75MV4OXgE8hG2WPMgKcZYreT6ujcyx3VasPdR yfVWNBl0h97Kf9ATTIniEkbh9rHM68BK85MmO7XgCvwCicDdxE/xbjIK4p0fosCOGFmP o14Q== X-Gm-Message-State: AOAM5321+WcA1jlgw5uV8xpUBUiSsfPsCUUorSm3bu66OZU4JmYkHwQD 3RmmbCa/kIe/poGPXZ8VZsTVRnUlNLk1m/SzAeA= X-Received: by 2002:aca:3d85:: with SMTP id k127mr47022oia.157.1613146455073; Fri, 12 Feb 2021 08:14:15 -0800 (PST) MIME-Version: 1.0 References: <20210208030723.781-1-zbestahu@gmail.com> In-Reply-To: <20210208030723.781-1-zbestahu@gmail.com> From: "Rafael J. Wysocki" Date: Fri, 12 Feb 2021 17:14:03 +0100 Message-ID: Subject: Re: [PATCH] cpufreq: schedutil: Don't use the limits_changed flag any more To: Yue Hu Cc: "Rafael J. Wysocki" , Rafael Wysocki , Viresh Kumar , Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Benjamin Segall , Mel Gorman , Daniel Bristot de Oliveira , Linux PM , Linux Kernel Mailing List , Yue Hu , zbestahu@163.com, zhangwen@yulong.com Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Feb 8, 2021 at 4:08 AM Yue Hu wrote: > > From: Yue Hu > > The limits_changed flag was introduced by commit 600f5badb78c > ("cpufreq: schedutil: Don't skip freq update when limits change") due > to race condition where need_freq_update is cleared in get_next_freq() > which causes reducing the CPU frequency is ineffective while busy. > > But now, the race condition above is gone because get_next_freq() > doesn't clear the flag any more after commit 23a881852f3e ("cpufreq: > schedutil: Don't skip freq update if need_freq_update is set"). > > Moreover, need_freq_update currently will be set to true only in > sugov_should_update_freq() if CPUFREQ_NEED_UPDATE_LIMITS is not set > for the driver. However, limits may have changed at any time. Yes, they may change at any time. > And subsequent frequence update is depending on need_freq_update. I'm not following, sorry. need_freq_update is set in sugov_should_update_freq() when limits_changed is cleared and it cannot be modified until sugov_update_next_freq() runs on the same CPU. > So, we may skip this update. I'm not sure why? > Hence, let's remove it to avoid above issue and make code more simple. > > Signed-off-by: Yue Hu > --- > kernel/sched/cpufreq_schedutil.c | 11 +++-------- > 1 file changed, 3 insertions(+), 8 deletions(-) > > diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c > index 41e498b..7dd85fb 100644 > --- a/kernel/sched/cpufreq_schedutil.c > +++ b/kernel/sched/cpufreq_schedutil.c > @@ -40,7 +40,6 @@ struct sugov_policy { > struct task_struct *thread; > bool work_in_progress; > > - bool limits_changed; > bool need_freq_update; > }; > > @@ -89,11 +88,8 @@ static bool sugov_should_update_freq(struct sugov_policy *sg_policy, u64 time) > if (!cpufreq_this_cpu_can_update(sg_policy->policy)) > return false; > > - if (unlikely(sg_policy->limits_changed)) { > - sg_policy->limits_changed = false; > - sg_policy->need_freq_update = true; > + if (unlikely(sg_policy->need_freq_update)) > return true; > - } > > delta_ns = time - sg_policy->last_freq_update_time; > > @@ -323,7 +319,7 @@ static bool sugov_cpu_is_busy(struct sugov_cpu *sg_cpu) > static inline void ignore_dl_rate_limit(struct sugov_cpu *sg_cpu, struct sugov_policy *sg_policy) > { > if (cpu_bw_dl(cpu_rq(sg_cpu->cpu)) > sg_cpu->bw_dl) > - sg_policy->limits_changed = true; > + sg_policy->need_freq_update = true; > } > > static inline bool sugov_update_single_common(struct sugov_cpu *sg_cpu, > @@ -759,7 +755,6 @@ static int sugov_start(struct cpufreq_policy *policy) > sg_policy->last_freq_update_time = 0; > sg_policy->next_freq = 0; > sg_policy->work_in_progress = false; > - sg_policy->limits_changed = false; > sg_policy->cached_raw_freq = 0; > > sg_policy->need_freq_update = cpufreq_driver_test_flags(CPUFREQ_NEED_UPDATE_LIMITS); > @@ -813,7 +808,7 @@ static void sugov_limits(struct cpufreq_policy *policy) > mutex_unlock(&sg_policy->work_lock); > } > > - sg_policy->limits_changed = true; > + sg_policy->need_freq_update = true; This may be running in parallel with sugov_update_next_freq() on a different CPU, so the latter may clear need_freq_update right after it has been set here unless I'm overlooking something. > } > > struct cpufreq_governor schedutil_gov = { > -- > 1.9.1 >