From patchwork Mon Mar 20 17:26:01 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: James Morse X-Patchwork-Id: 6914 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:604a:0:0:0:0:0 with SMTP id j10csp1348882wrt; Mon, 20 Mar 2023 10:49:39 -0700 (PDT) X-Google-Smtp-Source: AK7set8i/QscKbWvrdqtTE8Wc/Bj0oRXm4BPhQksc9hm9+8mKm9hOOchBVjtG5GUpfanJQzq5i3A X-Received: by 2002:a17:90a:354:b0:233:ee67:8eb3 with SMTP id 20-20020a17090a035400b00233ee678eb3mr21212454pjf.24.1679334579159; Mon, 20 Mar 2023 10:49:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1679334579; cv=none; d=google.com; s=arc-20160816; b=jgKHzDOdyvoI187oTWFRX26KRQ0tSP5zXJfF2DGvYxrzEw3QpZVfBI9rAP3T1oCs+l WBBhWkHBnbdT9Q16uw29N8KzL6/vWANu8XVkd7BKl5ItmOek1UL4Jz14nq7uWRrrgETs qg0jH8hPE/uHv23WJ7mtY2FifiN2XbIMegaoM/JEM1nPOT23UjTbpnPVo6mYAF0OHh/7 9sWRn9ZGQSKtSq8ovjUM8VIog2dwf4su+IiGS+bSS6Jex+iLZLrZ02oMncdCwjPFuQi6 pZlo9lzNWbJPmoiQi0PzsfwIdGZA3KflVOMAtlsWGoSwA3IYYcx0Pjgv/AP+qD5uyeYJ phvg== 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 :message-id:date:subject:cc:to:from; bh=4LTTOpYJJMTzrtXmmCJ6Zp9v+yGrMsu453VpU3wo01g=; b=jSXnFEJ9iD+KltScBZ6boBVqPznDxpOaIA7vem3ecRV4ZMmfDsLicavSitaMYXO416 B0eW9RDhS6zgATnJpzb3N5T0d0h6TcKFKl97Wxab8GYeLGNXu/m0Q27i8iZQ5FyzRQv1 rl39WidCcLepyKpOWWTfAR4RChORCGMgEgyRjQiqtEYlKmPctxIMf7PkzxFPvoYYDe3t Lfu3wO6qmNAtLsM4lbUTO4l0YYKf4KbnJgZ8oaKoim0UKInCRYx3LDs/EeFtvOObi0Dh J7FGemByMj2tecuTd19Fmy3ymMJeSeQfxX0iCtmLutsyIu5WjgyrwgL5BWq9sLi9pmH5 0tcw== 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=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id br22-20020a17090b0f1600b0023d3ecf85c5si10591591pjb.59.2023.03.20.10.49.23; Mon, 20 Mar 2023 10:49:39 -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=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233182AbjCTRcU (ORCPT + 99 others); Mon, 20 Mar 2023 13:32:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33562 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232810AbjCTRcA (ORCPT ); Mon, 20 Mar 2023 13:32:00 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id A30A439CF9 for ; Mon, 20 Mar 2023 10:27:38 -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 BC6E41FB; Mon, 20 Mar 2023 10:27:24 -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 45E173F67D; Mon, 20 Mar 2023 10:26:38 -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 Subject: [PATCH v3 00/19] x86/resctrl: monitored closid+rmid together, separate arch/fs locking Date: Mon, 20 Mar 2023 17:26:01 +0000 Message-Id: <20230320172620.18254-1-james.morse@arm.com> X-Mailer: git-send-email 2.20.1 MIME-Version: 1.0 X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_NONE autolearn=ham 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 X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1760909935226721096?= X-GMAIL-MSGID: =?utf-8?q?1760909935226721096?= Hello! The largest change since v2 is to avoid running work on nohz_full CPUs. Otherwise changes since v2 are noted in each patch. ~ This series does two things, it changes resctrl to call resctrl_arch_rmid_read() in a way that works for MPAM, and it separates the locking so that the arch code and filesystem code don't have to share a mutex. I tried to split this as two series, but these touch similar call sites, so it would create more work. (What's MPAM? See the cover letter of the first series. [1]) On x86 the RMID is an independent number. MPAMs equivalent is PMG, but this isn't an independent number - it extends the PARTID (same as CLOSID) space with bits that aren't used to select the configuration. The monitors can then be told to match specific PMG values, allowing monitor-groups to be created. But, MPAM expects the monitors to always monitor by PARTID. The Cache-storage-utilisation counters can only work this way. (In the MPAM spec not setting the MATCH_PARTID bit is made CONSTRAINED UNPREDICTABLE - which is Arm's term to mean portable software can't rely on this) It gets worse, as some SoCs may have very few PMG bits. I've seen the datasheet for one that has a single bit of PMG space. To be usable, MPAM's counters always need the PARTID and the PMG. For resctrl, this means always making the CLOSID available when the RMID is used. To ensure RMID are always unique, this series combines the CLOSID and RMID into an index, and manages RMID based on that. For x86, the index and RMID would always be the same. Currently the architecture specific code in the cpuhp callbacks takes the rdtgroup_mutex. This means the filesystem code would have to export this lock, resulting in an ill-defined interface between the two, and the possibility of cross-architecture lock-ordering head aches. The second part of this series adds a domain_list_lock to protect writes to the domain list, and protects the domain list with RCU - or read_cpus_lock(). Use of RCU is to allow lockless readers of the domain list, today resctrl only has one, rdt_bit_usage_show(). But to get MPAMs monitors working, its very likely they'll need to be plumbed up to perf. The uncore PMU driver would be a second lockless reader of the domain list. This series is based on v6.3-rc1, and can be retrieved from: https://git.kernel.org/pub/scm/linux/kernel/git/morse/linux.git mpam/monitors_and_locking/v3 Bugs welcome, Thanks, James [1] https://lore.kernel.org/lkml/20210728170637.25610-1-james.morse@arm.com/ [v1] https://lore.kernel.org/all/20221021131204.5581-1-james.morse@arm.com/ [v2] https://lore.kernel.org/lkml/20230113175459.14825-1-james.morse@arm.com/ James Morse (19): x86/resctrl: Track the closid with the rmid x86/resctrl: Access per-rmid structures by index x86/resctrl: Create helper for RMID allocation and mondata dir creation x86/resctrl: Move rmid allocation out of mkdir_rdt_prepare() x86/resctrl: Allow RMID allocation to be scoped by CLOSID x86/resctrl: Allow the allocator to check if a CLOSID can allocate clean RMID x86/resctrl: Move CLOSID/RMID matching and setting to use helpers x86/resctrl: Add cpumask_any_housekeeping() for limbo/overflow x86/resctrl: Queue mon_event_read() instead of sending an IPI x86/resctrl: Allow resctrl_arch_rmid_read() to sleep x86/resctrl: Allow arch to allocate memory needed in resctrl_arch_rmid_read() x86/resctrl: Make resctrl_mounted checks explicit x86/resctrl: Move alloc/mon static keys into helpers x86/resctrl: Make rdt_enable_key the arch's decision to switch x86/resctrl: Add helpers for system wide mon/alloc capable x86/resctrl: Add cpu online callback for resctrl work x86/resctrl: Allow overflow/limbo handlers to be scheduled on any-but cpu x86/resctrl: Add cpu offline callback for resctrl work x86/resctrl: Separate arch and fs resctrl locks arch/x86/include/asm/resctrl.h | 90 ++++++ arch/x86/kernel/cpu/resctrl/core.c | 78 ++--- arch/x86/kernel/cpu/resctrl/ctrlmondata.c | 23 +- arch/x86/kernel/cpu/resctrl/internal.h | 77 ++++- arch/x86/kernel/cpu/resctrl/monitor.c | 372 ++++++++++++++++------ arch/x86/kernel/cpu/resctrl/pseudo_lock.c | 15 +- arch/x86/kernel/cpu/resctrl/rdtgroup.c | 319 ++++++++++++++----- include/linux/resctrl.h | 21 +- include/linux/tick.h | 3 +- 9 files changed, 750 insertions(+), 248 deletions(-)