Received: by 2002:a05:6358:11c7:b0:104:8066:f915 with SMTP id i7csp3167496rwl; Mon, 27 Mar 2023 10:06:18 -0700 (PDT) X-Google-Smtp-Source: AK7set81xTnvQRgmJQ2TWtyrcjuqwqvU3ntyNb10XHtfEXs5KAGV/LDgvq0RHnuJvJzn1ALZJ4x4 X-Received: by 2002:a05:6a20:2921:b0:d5:f7f5:85e4 with SMTP id t33-20020a056a20292100b000d5f7f585e4mr10707771pzf.22.1679936777965; Mon, 27 Mar 2023 10:06:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1679936777; cv=none; d=google.com; s=arc-20160816; b=GwQunRJhM6HIgpRvKbruqef9mmcJ8fR8/mJSkQ5kYG0I1ZI98wiws6f6/3ZX3MF4vA AYYW77qtKZUMZGmxoHjk8721jx44NbikLjza7Vxo56x2FvifgKW3JbpRFRIgsJXG40sZ COGsAig0hxmRKE0OOAFwDERxTREpQX/jRGBBNKVVPo5l46cTMEcuJhI5zYmNh4qbLKYc S75ILP8gNAJpxRP8U+IngjurPyhYpng7Z5YTt6q2KVGU3vCBK+sGaEoWIz9jHgzRGEvZ AkYM9SIVb5Nh+lq6mZzXODyS7gwbRs4SmZW8339gNhDySZhB0eypYHq3McIRyqpQpi/q r7yw== 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=UHA4LFSWXYbIR36mt0GhteZWcZFuGHTN5HecZS8/pIE=; b=vUtwuil7dcsbgrm9zRzioNF3mx8wF3o624xya8uG/KWaPL74pweZQRGyOzaJX0uePh vx8LAMUYDlvlmzP8fXqrIipHeS+/E1jZt+MqjP1v4DpgS3MVfu00dHaEn/YpcLCuOGzR s1cYKdz3lCXBrwol97w4/urntYuTkttxvZs8SHqgO/Jx2t1J18ofYm9EicOCOntboAP0 mALJFc8Z154db7/N1mC1a3gD1gQEzXpy4vDoS1xoDTgPwgyQbs89ESY3Q67DuldBug9T jvCTq4GCdMAkQQQb4D8kxEO433rhd5FZoa6lUtRaR1WWc7ACimpNt0CP4sqSLq/A9TQ5 Fv6w== 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 o73-20020a62cd4c000000b00627fd9b86ccsi15307435pfg.136.2023.03.27.10.06.04; Mon, 27 Mar 2023 10:06:17 -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 S232874AbjC0RFU convert rfc822-to-8bit (ORCPT + 99 others); Mon, 27 Mar 2023 13:05:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54436 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232484AbjC0RFC (ORCPT ); Mon, 27 Mar 2023 13:05:02 -0400 Received: from mail-ed1-f41.google.com (mail-ed1-f41.google.com [209.85.208.41]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id ABFE2659E; Mon, 27 Mar 2023 10:03:40 -0700 (PDT) Received: by mail-ed1-f41.google.com with SMTP id b20so39094090edd.1; Mon, 27 Mar 2023 10:03:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679936599; 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=NrDYYOMYb+x8U/wfL/PFhG97cTznz+G4jcEke1v/IHU=; b=EwbSTXreQsrMaHpCFAoZ4myc0v9x3hDILiBAVzvBtLhWJ4a7be3+nyBi2cA3OT8kb1 gH3KlFfbu3NF99r9i1AKa3V8qoow7ZygUs4bcSjJ47PEy39Mc41wwJHJkvNai7DY1lsx 2xt5ulPeQ2GV7lleDox46L27PwzX2L5zRjPnZk9KV31JqOwdme1ktBHQZokb/W2NtoOf O9u/rr6QS8k0/jmuUXOPbe3I+JYb/3JMFEAuLm/ERpXqsvUws/el34GpYDcsdl0aQn8X 1Gb/Dm4dpgOLbTsBxm2NMiC0MKTjagkPcnAJNSU/ojTRWocPpq/F7QwrbRRH2QXum19k lQ2Q== X-Gm-Message-State: AAQBX9c7NddHwgEXVqwzScSUudcA8GGfxHOJGe9iSWRRXDXi13MFtoRJ jSV0Wxna18KutGb4FNYQuc7RuwKSTCcbO8Mw3ghrZ6NG X-Received: by 2002:a50:d54f:0:b0:502:4f7:d287 with SMTP id f15-20020a50d54f000000b0050204f7d287mr6124726edj.3.1679936599286; Mon, 27 Mar 2023 10:03:19 -0700 (PDT) MIME-Version: 1.0 References: <20230207051105.11575-1-ricardo.neri-calderon@linux.intel.com> <20230207051105.11575-22-ricardo.neri-calderon@linux.intel.com> In-Reply-To: <20230207051105.11575-22-ricardo.neri-calderon@linux.intel.com> From: "Rafael J. Wysocki" Date: Mon, 27 Mar 2023 19:03:08 +0200 Message-ID: Subject: Re: [PATCH v3 21/24] thermal: intel: hfi: Implement model-specific checks for task classification To: Ricardo Neri Cc: "Peter Zijlstra (Intel)" , Juri Lelli , Vincent Guittot , Ricardo Neri , "Ravi V. Shankar" , Ben Segall , Daniel Bristot de Oliveira , Dietmar Eggemann , Len Brown , Mel Gorman , "Rafael J. Wysocki" , Srinivas Pandruvada , Steven Rostedt , Tim Chen , Valentin Schneider , Lukasz Luba , Ionela Voinescu , x86@kernel.org, "Joel Fernandes (Google)" , linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, "Tim C . Chen" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT X-Spam-Status: No, score=0.5 required=5.0 tests=FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS 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, Feb 7, 2023 at 6:02 AM Ricardo Neri wrote: > > In Alder Lake and Raptor Lake, the result of thread classification is more > accurate when only one SMT sibling is busy. Classification results for > class 2 and 3 are always reliable. > > To avoid unnecessary migrations, only update the class of a task if it has > been the same during 4 consecutive user ticks. > > Cc: Ben Segall > Cc: Daniel Bristot de Oliveira > Cc: Dietmar Eggemann > Cc: Ionela Voinescu > Cc: Joel Fernandes (Google) > Cc: Len Brown > Cc: Lukasz Luba > Cc: Mel Gorman > Cc: Rafael J. Wysocki > Cc: Srinivas Pandruvada > Cc: Steven Rostedt > Cc: Tim C. Chen > Cc: Valentin Schneider > Cc: x86@kernel.org > Cc: linux-pm@vger.kernel.org > Cc: linux-kernel@vger.kernel.org > Signed-off-by: Ricardo Neri > --- > Changes since v2: > * None > > Changes since v1: > * Adjusted the result the classification of Intel Thread Director to start > at class 1. Class 0 for the scheduler means that the task is > unclassified. > * Used the new names of the IPC classes members in task_struct. > * Reworked helper functions to use sched_smt_siblings_idle() to query > the idle state of the SMT siblings of a CPU. > --- > drivers/thermal/intel/intel_hfi.c | 60 ++++++++++++++++++++++++++++++- > 1 file changed, 59 insertions(+), 1 deletion(-) > > diff --git a/drivers/thermal/intel/intel_hfi.c b/drivers/thermal/intel/intel_hfi.c > index 35d947f47550..fdb53e4cabc1 100644 > --- a/drivers/thermal/intel/intel_hfi.c > +++ b/drivers/thermal/intel/intel_hfi.c > @@ -40,6 +40,7 @@ > #include > > #include > +#include > > #include "../thermal_core.h" > #include "intel_hfi.h" > @@ -209,9 +210,64 @@ static int __percpu *hfi_ipcc_scores; > */ > #define HFI_UNCLASSIFIED_DEFAULT 1 > > +#define CLASS_DEBOUNCER_SKIPS 4 > + > +/** > + * debounce_and_update_class() - Process and update a task's classification > + * > + * @p: The task of which the classification will be updated > + * @new_ipcc: The new IPC classification > + * > + * Update the classification of @p with the new value that hardware provides. > + * Only update the classification of @p if it has been the same during > + * CLASS_DEBOUNCER_SKIPS consecutive ticks. > + */ > +static void debounce_and_update_class(struct task_struct *p, u8 new_ipcc) > +{ > + u16 debounce_skip; > + > + /* The class of @p changed. Only restart the debounce counter. */ > + if (p->ipcc_tmp != new_ipcc) { > + p->ipcc_cntr = 1; > + goto out; > + } > + > + /* > + * The class of @p did not change. Update it if it has been the same > + * for CLASS_DEBOUNCER_SKIPS user ticks. > + */ > + debounce_skip = p->ipcc_cntr + 1; > + if (debounce_skip < CLASS_DEBOUNCER_SKIPS) > + p->ipcc_cntr++; > + else > + p->ipcc = new_ipcc; > + > +out: > + p->ipcc_tmp = new_ipcc; > +} Why does the code above belong to the Intel HFI driver? It doesn't look like there is anything driver-specific in it. > + > +static bool classification_is_accurate(u8 hfi_class, bool smt_siblings_idle) > +{ > + switch (boot_cpu_data.x86_model) { > + case INTEL_FAM6_ALDERLAKE: > + case INTEL_FAM6_ALDERLAKE_L: > + case INTEL_FAM6_RAPTORLAKE: > + case INTEL_FAM6_RAPTORLAKE_P: > + case INTEL_FAM6_RAPTORLAKE_S: > + if (hfi_class == 3 || hfi_class == 2 || smt_siblings_idle) > + return true; > + > + return false; > + > + default: > + return true; > + } > +} > + > void intel_hfi_update_ipcc(struct task_struct *curr) > { > union hfi_thread_feedback_char_msr msr; > + bool idle; > > /* We should not be here if ITD is not supported. */ > if (!cpu_feature_enabled(X86_FEATURE_ITD)) { > @@ -227,7 +283,9 @@ void intel_hfi_update_ipcc(struct task_struct *curr) > * 0 is a valid classification for Intel Thread Director. A scheduler > * IPCC class of 0 means that the task is unclassified. Adjust. > */ > - curr->ipcc = msr.split.classid + 1; > + idle = sched_smt_siblings_idle(task_cpu(curr)); > + if (classification_is_accurate(msr.split.classid, idle)) > + debounce_and_update_class(curr, msr.split.classid + 1); > } I still think that this function should just return a number, possibly including a special "no IPCC" value. It may be passed a bool argument indicating whether or not the SMT siblings are idle. > > unsigned long intel_hfi_get_ipcc_score(unsigned short ipcc, int cpu) > --