Received: by 2002:a05:7412:31a9:b0:e2:908c:2ebd with SMTP id et41csp4062264rdb; Thu, 14 Sep 2023 10:32:38 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEU3ijNAKd5IQzo7sSGweVsXp8sHFd98hQoSEVR1Zeh45RRvm6EersaByL3IFa343O8C1Wb X-Received: by 2002:a17:902:e744:b0:1c3:e9b0:baf7 with SMTP id p4-20020a170902e74400b001c3e9b0baf7mr5958787plf.64.1694712758017; Thu, 14 Sep 2023 10:32:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1694712758; cv=none; d=google.com; s=arc-20160816; b=QVT5plT1AUPm1OyqmHDvCpv+GEZAysPPcb97FuYmlBL4hBeks03o1PgpRIgrmMLeBv g5omXal6UFTG6Wm3Hbz/j5GJuCPmhlA3snKgEXCHQiU0zxxYNNgtXeH4b+5tPtyBq+au T9TtGHQx3IqodhjT8XKb7wVq6BWImWax/UMB4AVooYak5RYjUWyqhzRLfk1uHJz1tBYY PwfEGGNVlRAGw6DrsF+VQfu8HOvDHoJmLFTG2g+Xx35STwfXmJfOxz+8inoZzMVtgMj7 BCTNde1aCpEVG6oWlQF0kIvCceAaUzcCmakoqjjIgxu1dx5liMHjHgCVQIVX6FUWYEla o5RA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=o6vrYh4PK8VDBMU1Y0WuKyuN/hWSc0k0Pn9K0zHsRSA=; fh=6Nl2MjDBXofbhMXyzAhf7L7loTtEBflFxRNey74qSFc=; b=O3hEY9OQmETU2NAFAEQMO+rU0XqIITfnTs2XfWxMAX+XiD36vmamNL0LgEdTnckZ/Z R1mDS8A0ikfDu+rx+UhS4SQNKxp546MZG0nN87X6ITcRJa9SbqDlo4EnHTBb8rQoO95F 3ozDhb7T7C3HkfQurExpNMfV3Qm4N9C8g2uTdOosx17vH1v3AnCmRue4/v8SC9pwjMWN DWArS4AuGUUcIowPuzsELj03g6T8RhD+70rZEPMsy1pbXzM3vn3GfXur6vIGbTvAjhl9 FjughYisp6B7REqIfdRkDjj0H0Ig6xXomxJlT2VEG7naj4DExFCmLRugqqVPNyWuY0W5 lMFA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 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 snail.vger.email (snail.vger.email. [23.128.96.37]) by mx.google.com with ESMTPS id y16-20020a17090322d000b001bbcb3d9265si158695plg.68.2023.09.14.10.32.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 14 Sep 2023 10:32:38 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) client-ip=23.128.96.37; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by snail.vger.email (Postfix) with ESMTP id 3B636821ADBB; Thu, 14 Sep 2023 10:23:19 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at snail.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239899AbjINRXV (ORCPT + 99 others); Thu, 14 Sep 2023 13:23:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33646 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239042AbjINRWz (ORCPT ); Thu, 14 Sep 2023 13:22:55 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 25EBA2D49 for ; Thu, 14 Sep 2023 10:22:36 -0700 (PDT) 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 15AFA11FB; Thu, 14 Sep 2023 10:23:13 -0700 (PDT) Received: from merodach.members.linode.com (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 13B483F5A1; Thu, 14 Sep 2023 10:22:32 -0700 (PDT) From: James Morse To: x86@kernel.org, linux-kernel@vger.kernel.org Cc: Fenghua Yu , Reinette Chatre , Thomas Gleixner , Ingo Molnar , Borislav Petkov , H Peter Anvin , Babu Moger , James Morse , shameerali.kolothum.thodi@huawei.com, D Scott Phillips OS , carl@os.amperecomputing.com, lcherian@marvell.com, bobo.shaobowang@huawei.com, tan.shaopeng@fujitsu.com, xingxin.hx@openanolis.org, baolin.wang@linux.alibaba.com, Jamie Iles , Xin Hao , peternewman@google.com, dfustini@baylibre.com, amitsinght@marvell.com Subject: [PATCH v6 13/24] x86/resctrl: Queue mon_event_read() instead of sending an IPI Date: Thu, 14 Sep 2023 17:21:27 +0000 Message-Id: <20230914172138.11977-14-james.morse@arm.com> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20230914172138.11977-1-james.morse@arm.com> References: <20230914172138.11977-1-james.morse@arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (snail.vger.email [0.0.0.0]); Thu, 14 Sep 2023 10:23:19 -0700 (PDT) Intel is blessed with an abundance of monitors, one per RMID, that can be read from any CPU in the domain. MPAMs monitors reside in the MMIO MSC, the number implemented is up to the manufacturer. This means when there are fewer monitors than needed, they need to be allocated and freed. MPAM's CSU monitors are used to back the 'llc_occupancy' monitor file. The CSU counter is allowed to return 'not ready' for a small number of micro-seconds after programming. To allow one CSU hardware monitor to be used for multiple control or monitor groups, the CPU accessing the monitor needs to be able to block when configuring and reading the counter. Worse, the domain may be broken up into slices, and the MMIO accesses for each slice may need performing from different CPUs. These two details mean MPAMs monitor code needs to be able to sleep, and IPI another CPU in the domain to read from a resource that has been sliced. mon_event_read() already invokes mon_event_count() via IPI, which means this isn't possible. On systems using nohz-full, some CPUs need to be interrupted to run kernel work as they otherwise stay in user-space running realtime workloads. Interrupting these CPUs should be avoided, and scheduling work on them may never complete. Change mon_event_read() to pick a housekeeping CPU, (one that is not using nohz_full) and schedule mon_event_count() and wait. If all the CPUs in a domain are using nohz-full, then an IPI is used as the fallback. This function is only used in response to a user-space filesystem request (not the timing sensitive overflow code). This allows MPAM to hide the slice behaviour from resctrl, and to keep the monitor-allocation in monitor.c. When the IPI fallback is used on machines where MPAM needs to make an access on multiple CPUs, the counter read will always fail. Reviewed-by: Shaopeng Tan Tested-by: Shaopeng Tan Reviewed-by: Peter Newman Tested-by: Peter Newman Signed-off-by: James Morse --- Changes since v2: * Use cpumask_any_housekeeping() and fallback to an IPI if needed. Changes since v3: * Actually include the IPI fallback code. Changes since v4: * Tinkered with existing capitalisation. --- arch/x86/kernel/cpu/resctrl/ctrlmondata.c | 28 +++++++++++++++++++++-- arch/x86/kernel/cpu/resctrl/monitor.c | 2 +- 2 files changed, 27 insertions(+), 3 deletions(-) diff --git a/arch/x86/kernel/cpu/resctrl/ctrlmondata.c b/arch/x86/kernel/cpu/resctrl/ctrlmondata.c index b44c487727d4..bd263b9a0abd 100644 --- a/arch/x86/kernel/cpu/resctrl/ctrlmondata.c +++ b/arch/x86/kernel/cpu/resctrl/ctrlmondata.c @@ -19,6 +19,7 @@ #include #include #include +#include #include "internal.h" /* @@ -520,12 +521,24 @@ int rdtgroup_schemata_show(struct kernfs_open_file *of, return ret; } +static int smp_mon_event_count(void *arg) +{ + mon_event_count(arg); + + return 0; +} + void mon_event_read(struct rmid_read *rr, struct rdt_resource *r, struct rdt_domain *d, struct rdtgroup *rdtgrp, int evtid, int first) { + int cpu; + + /* When picking a CPU from cpu_mask, ensure it can't race with cpuhp */ + lockdep_assert_held(&rdtgroup_mutex); + /* - * setup the parameters to send to the IPI to read the data. + * Setup the parameters to pass to mon_event_count() to read the data. */ rr->rgrp = rdtgrp; rr->evtid = evtid; @@ -534,7 +547,18 @@ void mon_event_read(struct rmid_read *rr, struct rdt_resource *r, rr->val = 0; rr->first = first; - smp_call_function_any(&d->cpu_mask, mon_event_count, rr, 1); + cpu = cpumask_any_housekeeping(&d->cpu_mask); + + /* + * cpumask_any_housekeeping() prefers housekeeping CPUs, but + * are all the CPUs nohz_full? If yes, pick a CPU to IPI. + * MPAM's resctrl_arch_rmid_read() is unable to read the + * counters on some platforms if its called in irq context. + */ + if (tick_nohz_full_cpu(cpu)) + smp_call_function_any(&d->cpu_mask, mon_event_count, rr, 1); + else + smp_call_on_cpu(cpu, smp_mon_event_count, rr, false); } int rdtgroup_mondata_show(struct seq_file *m, void *arg) diff --git a/arch/x86/kernel/cpu/resctrl/monitor.c b/arch/x86/kernel/cpu/resctrl/monitor.c index 993837e46db1..7749e6569a4a 100644 --- a/arch/x86/kernel/cpu/resctrl/monitor.c +++ b/arch/x86/kernel/cpu/resctrl/monitor.c @@ -587,7 +587,7 @@ static void mbm_bw_count(u32 closid, u32 rmid, struct rmid_read *rr) } /* - * This is called via IPI to read the CQM/MBM counters + * This is scheduled by mon_event_read() to read the CQM/MBM counters * on a domain. */ void mon_event_count(void *info) -- 2.39.2