Received: by 2002:a05:6358:9144:b0:117:f937:c515 with SMTP id r4csp6220387rwr; Tue, 9 May 2023 11:58:05 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ7TIgz56tOIUiRElGvjxyGOsU108xz3oCz8fsUELoDf38c5sqiju16NueQA1cDPodgqC8zi X-Received: by 2002:a05:6a20:3ca9:b0:100:1044:9ce2 with SMTP id b41-20020a056a203ca900b0010010449ce2mr12204140pzj.56.1683658684810; Tue, 09 May 2023 11:58:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1683658684; cv=none; d=google.com; s=arc-20160816; b=ZWPg31Wwy91glw4sNFK2J+68x3p7sn5E8+ryFRIlOWNArJHiVJGRtEcWVXiIYEwD4Z fN1MxOvZg3PJ0HFKtDLPXrtsaKciQCPjLMSP09gyN1Q7t/bMfHFYZ7X8XHGABF2Qnvuw 2bMAxWzy83tCKZ9i8wEpzkEhtsrCPlQcO4q+4NzSlOtX274vfi+pT3JUXVZYEkmyIjj6 ZWKFa+VbBTTNOA71MHMJVJ4x54CBWQt9gQrjJ5QW6PNAN+mmcF1Vv51agdJziI4+3w5o I4ujRlO7XInxP2+PQPot772cR55BJg8qo7G1LGoHga5NyZHNgXSTWoku0FnxSQzftC5H h+zA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version; bh=xxj2bILE04WdAxrsZV/3raGMLRsSTEKG4fLrJrRTLs4=; b=ODIkVxkQh9eyjCrz8udR+rZTVTF6/w4AZ1OF0dhSemW6An5nEEEqx/Kx/1GNZRrT+i ExKRDOAalnkv3lmFDzABS89ec75S3BF9ThE1om6SDSxB65I2MxfUgnF/2Nwjmoe038iU jQ3e1WaOKlnA9s6IJ2nvEt5xVUC++QJ9xSHLqiApyb9Z8ihmXgFYoyrtSFCo2sZEslK2 EXp56j03nmPK1Pj5brZzCEurk7I6jc64Jn/JKxjBbIxyuI+I63+MH/aL9T6jt+MS3THX /MbA76QnhlmLpavCooE4anF2kkEpV9pOikTKV0jGIRKUOY7CPFghHAYzuLvAtv2MBPZu 1Z3w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id c83-20020a624e56000000b0063d2b810fc6si2995923pfb.305.2023.05.09.11.57.51; Tue, 09 May 2023 11:58:04 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 S234764AbjEISjo convert rfc822-to-8bit (ORCPT + 99 others); Tue, 9 May 2023 14:39:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58628 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229656AbjEISjn (ORCPT ); Tue, 9 May 2023 14:39:43 -0400 Received: from mail-ej1-f44.google.com (mail-ej1-f44.google.com [209.85.218.44]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 62B13359D; Tue, 9 May 2023 11:39:35 -0700 (PDT) Received: by mail-ej1-f44.google.com with SMTP id a640c23a62f3a-965aa9d1d19so173776366b.0; Tue, 09 May 2023 11:39:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683657574; x=1686249574; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Fk4TDLP8eBXdwBhXU6v4XzEa25SJ2T9VAd0f2AbruVE=; b=HsKXg5j7xn2DroMQ8N8hGVgmdHNK6LCiW+giePIR740uT85/nWHknVePCX6fv7bBfA EcOIRehJ+k2ipfZkexvMttUrWkrFwZK5DdnJ6npb+d963lH1vaxYED2+csO28NDE4krz A1zEZeSOo68v+eFd0LaTt+EukaHM2ZyplbmrLqtJjGVthl2Zh8ZbrDXubBHBdTjyEDLq hA3ugGvkzqqshvFDWUGYvwCMQVIIklwmLWAPsNfXOO652vOburzb/YAyqIO5gtNJUIZM XKW3bab0561RYrKjfaLQ7ppNEKzIL+9h7OgPiD5IY1xSgNSdhlneJhofvW7SjHQeeIyf NhxA== X-Gm-Message-State: AC+VfDzCXG/OAxciPSb1hXhgC6FB3wAh7b/MYMpDf1+nsWGZ5r2giT9B uGlyWwdn8mrsAyl/0Hes0Au9CXMsp3BPxwpJUFw= X-Received: by 2002:a17:906:518a:b0:959:37cc:190e with SMTP id y10-20020a170906518a00b0095937cc190emr11911985ejk.3.1683657573653; Tue, 09 May 2023 11:39:33 -0700 (PDT) MIME-Version: 1.0 References: <20230509180503.739208-1-wyes.karny@amd.com> <20230509180503.739208-2-wyes.karny@amd.com> In-Reply-To: From: "Rafael J. Wysocki" Date: Tue, 9 May 2023 20:39:22 +0200 Message-ID: Subject: Re: [PATCH v2 1/2] cpufreq/schedutil: Remove fast_switch_possible flag if driver doesn't set fast_switch To: Wyes Karny Cc: ray.huang@amd.com, rafael@kernel.org, viresh.kumar@linaro.org, srinivas.pandruvada@linux.intel.com, lenb@kernel.org, mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com, vincent.guittot@linaro.org, dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de, joel@joelfernandes.org, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 9, 2023 at 8:18 PM Rafael J. Wysocki wrote: > > On Tue, May 9, 2023 at 8:06 PM Wyes Karny wrote: > > > > The set value of `fast_switch_enabled` indicates that fast_switch > > callback is set. BTW, this is not true. The ACPI cpufreq driver has fast_switch, but it doesn't always use it. > > For some drivers such as amd_pstate and intel_pstate, > > the adjust_perf callback is used but it still sets > > `fast_switch_possible` flag. This is because this flag also decides > > whether schedutil governor selects adjust_perf function for frequency > > update. This condition in the schedutil governor forces the scaling > > driver to set the `fast_switch_possible` flag. Yes, it does, but setting this flag is not sufficient. > > Remove `fast_switch_enabled` check when schedutil decides to select > > adjust_perf function for frequency update. Thus removing this drivers > > are now free to remove `fast_switch_possible` flag if they don't use > > fast_switch callback. > > > > This issue becomes apparent when aperf/mperf overflow occurs. When this > > happens, kernel disables frequency invariance calculation which causes > > schedutil to fallback to sugov_update_single_freq which currently relies > > on the fast_switch callback. > > > > Normal flow: > > sugov_update_single_perf > > cpufreq_driver_adjust_perf > > cpufreq_driver->adjust_perf > > > > Error case flow: > > sugov_update_single_perf > > sugov_update_single_freq <-- This is chosen because the freq invariant is disabled due to aperf/mperf overflow > > cpufreq_driver_fast_switch > > cpufreq_driver->fast_switch <-- Here NULL pointer dereference is happening, because fast_switch is not set > > So you need to set fast_switch. > > Please read the comment in sugov_update_single_perf(). It explains > why adjust_perf is not used when scale invariance is not enabled: the > mapping between the performance levels and frequency are not generally > defined in that case and it is up to the driver to figure out what > perf level to use to get the given frequency. And this is exactly why > fast_switch is not optional: because scale invariance may be disabled. > > Please feel free to update the documentation to clarify this, but the > way to fix the issue is to implement fast_switch in the driver. > > > Fixes: a61dec744745 ("cpufreq: schedutil: Avoid missing updates for one-CPU policies") > > Signed-off-by: Wyes Karny > > > > Cc: "Rafael J. Wysocki" > > Cc: stable@vger.kernel.org > > --- > > drivers/cpufreq/amd-pstate.c | 10 +++++++--- > > drivers/cpufreq/cpufreq.c | 20 +++++++++++++++++++- > > drivers/cpufreq/intel_pstate.c | 3 +-- > > include/linux/cpufreq.h | 1 + > > kernel/sched/cpufreq_schedutil.c | 2 +- > > 5 files changed, 29 insertions(+), 7 deletions(-) > > > > diff --git a/drivers/cpufreq/amd-pstate.c b/drivers/cpufreq/amd-pstate.c > > index 5a3d4aa0f45a..007bfe724a6a 100644 > > --- a/drivers/cpufreq/amd-pstate.c > > +++ b/drivers/cpufreq/amd-pstate.c > > @@ -671,8 +671,14 @@ static int amd_pstate_cpu_init(struct cpufreq_policy *policy) > > /* It will be updated by governor */ > > policy->cur = policy->cpuinfo.min_freq; > > > > + /** > > + * For shared memory system frequency update takes time that's why > > + * do this in deferred kthread context. > > + */ > > if (boot_cpu_has(X86_FEATURE_CPPC)) > > - policy->fast_switch_possible = true; > > + current_pstate_driver->adjust_perf = amd_pstate_adjust_perf; > > + else > > + current_pstate_driver->adjust_perf = NULL; > > > > ret = freq_qos_add_request(&policy->constraints, &cpudata->req[0], > > FREQ_QOS_MIN, policy->cpuinfo.min_freq); > > @@ -697,8 +703,6 @@ static int amd_pstate_cpu_init(struct cpufreq_policy *policy) > > policy->driver_data = cpudata; > > > > amd_pstate_boost_init(cpudata); > > - if (!current_pstate_driver->adjust_perf) > > - current_pstate_driver->adjust_perf = amd_pstate_adjust_perf; > > > > return 0; > > > > diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c > > index 6b52ebe5a890..366747012104 100644 > > --- a/drivers/cpufreq/cpufreq.c > > +++ b/drivers/cpufreq/cpufreq.c > > @@ -501,6 +501,13 @@ void cpufreq_enable_fast_switch(struct cpufreq_policy *policy) > > if (!policy->fast_switch_possible) > > return; > > > > + /** > > + * It's not expected driver's fast_switch callback is not set > > + * even fast_switch_possible is true. > > + */ > > + if (WARN_ON(!cpufreq_driver_has_fast_switch())) > > + return; > > + > > mutex_lock(&cpufreq_fast_switch_lock); > > if (cpufreq_fast_switch_count >= 0) { > > cpufreq_fast_switch_count++; > > @@ -2143,6 +2150,17 @@ unsigned int cpufreq_driver_fast_switch(struct cpufreq_policy *policy, > > } > > EXPORT_SYMBOL_GPL(cpufreq_driver_fast_switch); > > > > +/** > > + * cpufreq_driver_has_fast_switch - Check "fast switch" callback. > > + * > > + * Return 'true' if the ->fast_switch callback is present for the > > + * current driver or 'false' otherwise. > > + */ > > +bool cpufreq_driver_has_fast_switch(void) > > +{ > > + return !!cpufreq_driver->fast_switch; > > +} > > + > > /** > > * cpufreq_driver_adjust_perf - Adjust CPU performance level in one go. > > * @cpu: Target CPU. > > @@ -2157,7 +2175,7 @@ EXPORT_SYMBOL_GPL(cpufreq_driver_fast_switch); > > * and it is expected to select a suitable performance level equal to or above > > * @min_perf and preferably equal to or below @target_perf. > > * > > - * This function must not be called if policy->fast_switch_enabled is unset. > > + * By default this function takes the fast frequency update path. > > * > > * Governors calling this function must guarantee that it will never be invoked > > * twice in parallel for the same CPU and that it will never be called in > > diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c > > index 2548ec92faa2..007893514c87 100644 > > --- a/drivers/cpufreq/intel_pstate.c > > +++ b/drivers/cpufreq/intel_pstate.c > > @@ -2698,8 +2698,6 @@ static int __intel_pstate_cpu_init(struct cpufreq_policy *policy) > > > > intel_pstate_init_acpi_perf_limits(policy); > > > > - policy->fast_switch_possible = true; > > - > > return 0; > > } > > > > @@ -2955,6 +2953,7 @@ static int intel_cpufreq_cpu_init(struct cpufreq_policy *policy) > > if (ret) > > return ret; > > > > + policy->fast_switch_possible = true; I'm not sure what this is about. Is it a cleanup of intel_pstate? > > policy->cpuinfo.transition_latency = INTEL_CPUFREQ_TRANSITION_LATENCY; > > /* This reflects the intel_pstate_get_cpu_pstates() setting. */ > > policy->cur = policy->cpuinfo.min_freq; > > diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h > > index 26e2eb399484..7a32cfca26c9 100644 > > --- a/include/linux/cpufreq.h > > +++ b/include/linux/cpufreq.h > > @@ -604,6 +604,7 @@ struct cpufreq_governor { > > /* Pass a target to the cpufreq driver */ > > unsigned int cpufreq_driver_fast_switch(struct cpufreq_policy *policy, > > unsigned int target_freq); > > +bool cpufreq_driver_has_fast_switch(void); > > void cpufreq_driver_adjust_perf(unsigned int cpu, > > unsigned long min_perf, > > unsigned long target_perf, > > diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c > > index e3211455b203..f993ecf731a9 100644 > > --- a/kernel/sched/cpufreq_schedutil.c > > +++ b/kernel/sched/cpufreq_schedutil.c > > @@ -776,7 +776,7 @@ static int sugov_start(struct cpufreq_policy *policy) > > > > if (policy_is_shared(policy)) > > uu = sugov_update_shared; > > - else if (policy->fast_switch_enabled && cpufreq_driver_has_adjust_perf()) > > + else if (cpufreq_driver_has_adjust_perf()) > > uu = sugov_update_single_perf; > > else > > uu = sugov_update_single_freq; > > --