Message ID | 168177449635.1758847.13040588638888054027.stgit@bmoger-ubuntu |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp2474452vqo; Mon, 17 Apr 2023 16:50:29 -0700 (PDT) X-Google-Smtp-Source: AKy350aj4RzU4J6hhsTzzuFDNKJdJpybkReEKs9i3+i2pYh3A5Rfah7bvmJAqYbFvIK8yFz3Z8Ef X-Received: by 2002:a17:902:c613:b0:1a2:8c7e:f310 with SMTP id r19-20020a170902c61300b001a28c7ef310mr230854plr.35.1681775429733; Mon, 17 Apr 2023 16:50:29 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1681775429; cv=pass; d=google.com; s=arc-20160816; b=qOzxSKe/SWwdqcZG8jMScS8/Nyj6G1ONbDo3jvZ2cs2VQmj8HiaxBdH2kFb/sTUK1F ypA88UG6pUndBjsL5CVl22AO4raJz0XQABhdjBAuw07zw16cWx3/+xlW12bd6J7hEkkZ OhD5FF/w7mDVkAtTql8EIe9kj3cWa3p2KbzamCGEkrFCZwkc/DKjv9Ziq8smbioBQO4X TS8/9BtUAppAF6Rh8tB2di9newoYUIgU92+B1eBAjrNeHhvOIt1Zm6HTbq/1fmnuPEUY ygD1yoUL4bKstgZJgZzGWBPfA2n55MBxYQzgmmq07yGt4GiaGipMCe740/sWaBkhgRSJ YcMw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:cc:to:from :subject:dkim-signature; bh=Ybihj2KdjI+Z/hC4V5qabsSvdzEjuHKYdxCu5RXeBuE=; b=j0AI3b1rmsuF0yKkQX4I6bJSxMd7lpyZQdGHanGM2m0p6Ybx10eWoIlUdeOs2FG8KN ox0NvnrPAx5FqVt0m+qS+F3pBnlBVKSWWzGzU/AjfgeBc0GtGCBwmke2u453/p+VD7Q8 S2uTu7sutT4fZzQrNFVHb2nlwbR8qX8yD+kZZtdS3uN2nHswNKW3hG2HqI95Hz7Ib/6P dDXxKNrBtzWkDMZHwVtjrtmdGRa3Z/6TJFZfE2y7l2cvlJ0+mA6teIWOlbBQ4KdZBcZI htgFNcVARrMq5BBRusYBkLCC/c4YfnV9g3QKNzSxNp5Q8xvVK5SRApPlmb+hLLQfgYcp Fi6w== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@amd.com header.s=selector1 header.b=nvlQt+0K; arc=pass (i=1 spf=pass spfdomain=amd.com dmarc=pass fromdomain=amd.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=QUARANTINE sp=QUARANTINE dis=NONE) header.from=amd.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id x6-20020a1709028ec600b0019a9834bb23si12540264plo.192.2023.04.17.16.50.15; Mon, 17 Apr 2023 16:50:29 -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; dkim=pass header.i=@amd.com header.s=selector1 header.b=nvlQt+0K; arc=pass (i=1 spf=pass spfdomain=amd.com dmarc=pass fromdomain=amd.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=QUARANTINE sp=QUARANTINE dis=NONE) header.from=amd.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230075AbjDQXf4 (ORCPT <rfc822;leviz.kernel.dev@gmail.com> + 99 others); Mon, 17 Apr 2023 19:35:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58006 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229967AbjDQXfw (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 17 Apr 2023 19:35:52 -0400 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on2085.outbound.protection.outlook.com [40.107.243.85]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6022A59C7; Mon, 17 Apr 2023 16:35:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JLZIOyHLkgMCXL8jxQ2zQLBjiCra00FSTf1rPq+YZubaMDaDJuNxgODAxlLzS9TxEI1t2V1ByswTt+TvnxZK/6hSfreYTEMKjE3XRpgoYhsAdXLRoIkXzAaNiY6RzOtl7Q/qn3l4Xn7Nph8CfThoQJQXi16awGX3RWrgE2cNAbGgSljZBD88GKCvJe635p0PEOrdOC9u3H8XUlktB5bOipPC2cUp8/zcVpnX4NO7I7Z2E7MpigPG3ezEcedN7o7UmgBh1BFqF6pdlR1b7lO/oMqHuu2DfF+7OrhKg1z+hfzV0DQhiOcHxdMbqYeqzWHf9gfjj6C029uYCLxBVBjG8w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Ybihj2KdjI+Z/hC4V5qabsSvdzEjuHKYdxCu5RXeBuE=; b=cERSTkq3Qqv1dLqgQVzb2ZHQU1do3vNv5/otabDpaAHuKFsjkvPBxtO3tWB7F3mNKMRNvEWOPWYnJ53VXmNgwY+VwNpm/5jG4LCjw7xqCm7sauU9sKdbuCgRgFJcPz3uf3JO+ngcxVnQvMl8qJzKqCt727AHSUGgoem2GCytny095moBGgIisB/uRW4dH0z0IJw8GdT63Nl9wk2h6CodLZtMFkzbNkT3lNRyrhh24gWcQNxvQV9LmBHyFyXnt3HvqeZBfUXvxFvXzRus7DucjtNOjCf7yIqKoVC5XuroucIdrCLpcgnlulp038yM6VayaSekDbmuC3V5xo/mmRlutA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=infradead.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Ybihj2KdjI+Z/hC4V5qabsSvdzEjuHKYdxCu5RXeBuE=; b=nvlQt+0K4TQCMx4dN98BPpZ9iSCBUXMGYyTkdG/MhXFvSGjl3ogCCs0/7q9BohywSwCuyuAaRJoPnqVBsPrnq3tdMpS6CbCC3I2hqUGMqbFMQae2OLjRzSneVaS/Z3s9kYx/9/AeF4/BMnSUmL2PoTvo88623cbHWQS4FxWGPJ8= Received: from DM6PR13CA0066.namprd13.prod.outlook.com (2603:10b6:5:134::43) by DM4PR12MB5279.namprd12.prod.outlook.com (2603:10b6:5:39f::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6298.45; Mon, 17 Apr 2023 23:35:05 +0000 Received: from DM6NAM11FT037.eop-nam11.prod.protection.outlook.com (2603:10b6:5:134:cafe::c6) by DM6PR13CA0066.outlook.office365.com (2603:10b6:5:134::43) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6319.19 via Frontend Transport; Mon, 17 Apr 2023 23:35:05 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C Received: from SATLEXMB04.amd.com (165.204.84.17) by DM6NAM11FT037.mail.protection.outlook.com (10.13.172.122) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.6319.20 via Frontend Transport; Mon, 17 Apr 2023 23:35:05 +0000 Received: from [127.0.1.1] (10.180.168.240) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.34; Mon, 17 Apr 2023 18:35:02 -0500 Subject: [PATCH v4 6/7] x86/resctrl: Display CLOSID and RMID for the resctrl groups From: Babu Moger <babu.moger@amd.com> To: <corbet@lwn.net>, <reinette.chatre@intel.com>, <tglx@linutronix.de>, <mingo@redhat.com>, <bp@alien8.de> CC: <fenghua.yu@intel.com>, <dave.hansen@linux.intel.com>, <x86@kernel.org>, <hpa@zytor.com>, <paulmck@kernel.org>, <akpm@linux-foundation.org>, <quic_neeraju@quicinc.com>, <rdunlap@infradead.org>, <damien.lemoal@opensource.wdc.com>, <songmuchun@bytedance.com>, <peterz@infradead.org>, <jpoimboe@kernel.org>, <pbonzini@redhat.com>, <babu.moger@amd.com>, <chang.seok.bae@intel.com>, <pawan.kumar.gupta@linux.intel.com>, <jmattson@google.com>, <daniel.sneddon@linux.intel.com>, <sandipan.das@amd.com>, <tony.luck@intel.com>, <james.morse@arm.com>, <linux-doc@vger.kernel.org>, <linux-kernel@vger.kernel.org>, <bagasdotme@gmail.com>, <eranian@google.com>, <christophe.leroy@csgroup.eu>, <pawan.kumar.gupta@linux.intel.com>, <jarkko@kernel.org>, <adrian.hunter@intel.com>, <quic_jiles@quicinc.com>, <peternewman@google.com>, <babu.moger@amd.com> Date: Mon, 17 Apr 2023 18:34:56 -0500 Message-ID: <168177449635.1758847.13040588638888054027.stgit@bmoger-ubuntu> In-Reply-To: <168177435378.1758847.8317743523931859131.stgit@bmoger-ubuntu> References: <168177435378.1758847.8317743523931859131.stgit@bmoger-ubuntu> User-Agent: StGit/1.1.dev103+g5369f4c MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com (10.181.40.145) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DM6NAM11FT037:EE_|DM4PR12MB5279:EE_ X-MS-Office365-Filtering-Correlation-Id: 5db6958f-de84-47e6-5db6-08db3f9c5fa2 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: +qHLlN3NhxpQeXu/Oq7b94EFUb+/bAUXFOD7olAcz8QNr4y7oBjTkAsIBA+Qh8GZixOOkgBI8HowcOjFqbKS+3a9Ov1xF4Qgs47bdHIzK/2C8wPeD49Ij0qK90ZgerBSFpLp9Eg40ZuZzB4zRMWAZpRpODaVKxdXhjMlurSbZ/SBy7dKvLarKQSGrg3Ym+e1XRLQI/YgrDOWYzIbdUhb1HoscKHHJ9mUhlSArSibX7iCDm8WrPSWVJHrn/UJI6c2w6WIMHbnEZCKACYP4lTTD8GexjLnCgyCe9hE59ZWzGbIf2YH4RGaJBHWQEvWvKYju4ZqGNFX1gZKWaTVccc0d6EKST0FIZURqrb+DmfG29lQCZ/QH4F4rIogUiXFIgjKxgScaoLjcWRGTm1XW2k037BFf7ZQLo0NLU7BL7ArcVW5QSmBivvQyCjj3UYfzxcrry+ySmCgJehTXhqnE6wzDVQTWArQVDvCBVlWeoegkFmQKCCedatxqkOQ3uTMJbuXlOZm/+Z9Hdj6EyOMRV8JY2HLHehDoetE7kZUehMWEs5PcMNkM6mRBWSR3Z6aaj1d/dxVZQ/4pINxxKMuO3IRWJdxiQu+U8y9tMzh43gfbEu7BmrLx1af/EWurw4BMxBGcvGm7ybn4qiejEyXGnSqImDnuqoFEbmJJxc7xmuTDcoPE2Igd5rM7sZdcj37niMxhGbs6gxBm4JoqkmQ7fqO9YPCCY/l8UsB8nUVC6pJ/50oZ+3NAgGT1GKVxE1ugD64FA93WHJtH+4aLl4PoI3N1A== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230028)(7916004)(4636009)(396003)(376002)(136003)(39860400002)(346002)(451199021)(40470700004)(36840700001)(46966006)(36860700001)(16576012)(110136005)(9686003)(54906003)(26005)(33716001)(478600001)(82740400003)(70586007)(70206006)(47076005)(316002)(83380400001)(6666004)(186003)(16526019)(336012)(4326008)(426003)(41300700001)(356005)(8936002)(8676002)(2906002)(5660300002)(81166007)(7416002)(7406005)(44832011)(82310400005)(40460700003)(103116003)(40480700001)(86362001)(71626016)(36900700001);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Apr 2023 23:35:05.4200 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 5db6958f-de84-47e6-5db6-08db3f9c5fa2 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: DM6NAM11FT037.eop-nam11.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB5279 X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FORGED_SPF_HELO, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_NONE, 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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1763469352910343152?= X-GMAIL-MSGID: =?utf-8?q?1763469352910343152?= |
Series |
x86/resctrl: Miscellaneous resctrl features
|
|
Commit Message
Moger, Babu
April 17, 2023, 11:34 p.m. UTC
When a user creates a control or monitor group, the CLOSID or RMID
are not visible to the user. It can help to debug the issues in some
cases. There are only available with "-o debug" option.
Add CLOSID(ctrl_hw_id) and RMID(mon_hw_id) to the control/monitor groups
display in resctrl interface.
$cat /sys/fs/resctrl/clos1/clos_hw_id
1
$cat /sys/fs/resctrl/mon_groups/mon1/mon_hw_id
3
Signed-off-by: Babu Moger <babu.moger@amd.com>
---
Documentation/x86/resctrl.rst | 17 ++++++++++++
arch/x86/kernel/cpu/resctrl/rdtgroup.c | 44 ++++++++++++++++++++++++++++++++
2 files changed, 61 insertions(+)
Comments
On 4/18/23 06:34, Babu Moger wrote: > +"ctrl_hw_id": > + Available only with debug option. On x86, reading this file shows > + the Class of Service (CLOS) id which acts as a resource control > + tag on which the resources can be throttled. Kernel assigns a new > + CLOSID a control group is created depending on the available > + CLOSIDs. Multiple cores(or threads) or processes can share a > + same CLOSID in a resctrl group. > + > <snipped>... > +"mon_hw_id": > + Available only with debug option. On x86, reading this file shows > + the Resource Monitoring ID (RMID) for monitoring the resource > + utilization. Monitoring is performed by tagging each core (or > + thread) or process via a RMID. Kernel assigns a new RMID when > + a group is created depending on the available RMIDs. Multiple > + cores (or threads) or processes can share a same RMID in a > + resctrl group. > + Is CONFIG_DEBUG=y required?
On 4/17/23 21:22, Bagas Sanjaya wrote: > On 4/18/23 06:34, Babu Moger wrote: >> +"ctrl_hw_id": >> + Available only with debug option. On x86, reading this file shows >> + the Class of Service (CLOS) id which acts as a resource control >> + tag on which the resources can be throttled. Kernel assigns a new >> + CLOSID a control group is created depending on the available >> + CLOSIDs. Multiple cores(or threads) or processes can share a >> + same CLOSID in a resctrl group. >> + >> <snipped>... >> +"mon_hw_id": >> + Available only with debug option. On x86, reading this file shows >> + the Resource Monitoring ID (RMID) for monitoring the resource >> + utilization. Monitoring is performed by tagging each core (or >> + thread) or process via a RMID. Kernel assigns a new RMID when >> + a group is created depending on the available RMIDs. Multiple >> + cores (or threads) or processes can share a same RMID in a >> + resctrl group. >> + > > Is CONFIG_DEBUG=y required? No. Available with resctrl dubug option. Thanks Babu Moger
Hi Babu, On 4/17/2023 4:34 PM, Babu Moger wrote: > When a user creates a control or monitor group, the CLOSID or RMID > are not visible to the user. It can help to debug the issues in some > cases. There are only available with "-o debug" option. Please see: Documentation/process/maintainer-tip.rst "It's also useful to structure the changelog into several paragraphs and not lump everything together into a single one. A good structure is to explain the context, the problem and the solution in separate paragraphs and this order." > > Add CLOSID(ctrl_hw_id) and RMID(mon_hw_id) to the control/monitor groups Please highlight that CLOSID and RMID are x86 concepts. > display in resctrl interface. > $cat /sys/fs/resctrl/clos1/clos_hw_id > 1 This example does not match what the patch does (clos_hw_id -> ctrl_hw_id). I also think this change would be more palatable (to non x86 audience) if the example resource group has a generic (non-x86 concept) name. > $cat /sys/fs/resctrl/mon_groups/mon1/mon_hw_id > 3 > > Signed-off-by: Babu Moger <babu.moger@amd.com> > --- > Documentation/x86/resctrl.rst | 17 ++++++++++++ > arch/x86/kernel/cpu/resctrl/rdtgroup.c | 44 ++++++++++++++++++++++++++++++++ > 2 files changed, 61 insertions(+) > > diff --git a/Documentation/x86/resctrl.rst b/Documentation/x86/resctrl.rst > index be443251b484..5aff8c2beb08 100644 > --- a/Documentation/x86/resctrl.rst > +++ b/Documentation/x86/resctrl.rst > @@ -345,6 +345,14 @@ When control is enabled all CTRL_MON groups will also contain: > file. On successful pseudo-locked region creation the mode will > automatically change to "pseudo-locked". > > +"ctrl_hw_id": > + Available only with debug option. On x86, reading this file shows > + the Class of Service (CLOS) id which acts as a resource control > + tag on which the resources can be throttled. Kernel assigns a new > + CLOSID a control group is created depending on the available > + CLOSIDs. Multiple cores(or threads) or processes can share a > + same CLOSID in a resctrl group. Please keep other content from the documentation in mind when making this change. CLOSID is already documented, including the fact that it is a limited resource. Please see content under: "Notes on cache occupancy monitoring and control" where it, for example, states that "The number of CLOSid and RMID are limited by the hardware." Considering this the above could just read: "Available only with debug option. The identifier used by hardware for the control group. On x86 this is the CLOSID." Similar feedback to the "mon_hw_id" portion. Reinette
Hi Reinette, On 5/4/2023 2:04 PM, Reinette Chatre wrote: > Hi Babu, > > On 4/17/2023 4:34 PM, Babu Moger wrote: >> When a user creates a control or monitor group, the CLOSID or RMID >> are not visible to the user. It can help to debug the issues in some >> cases. There are only available with "-o debug" option. > Please see: Documentation/process/maintainer-tip.rst > > "It's also useful to structure the changelog into several paragraphs and not > lump everything together into a single one. A good structure is to explain > the context, the problem and the solution in separate paragraphs and this > order." ok Sure. >> Add CLOSID(ctrl_hw_id) and RMID(mon_hw_id) to the control/monitor groups > Please highlight that CLOSID and RMID are x86 concepts. ok Sure. > >> display in resctrl interface. >> $cat /sys/fs/resctrl/clos1/clos_hw_id >> 1 > This example does not match what the patch does (clos_hw_id -> ctrl_hw_id). My bad. Will fix it. > I also think this change would be more palatable (to non x86 audience) if > the example resource group has a generic (non-x86 concept) name. ok. In this example the clos1 name sounds x86 specific. I can change it to ctrl_grp1. Hope this is what you meant. > >> $cat /sys/fs/resctrl/mon_groups/mon1/mon_hw_id >> 3 >> >> Signed-off-by: Babu Moger <babu.moger@amd.com> >> --- >> Documentation/x86/resctrl.rst | 17 ++++++++++++ >> arch/x86/kernel/cpu/resctrl/rdtgroup.c | 44 ++++++++++++++++++++++++++++++++ >> 2 files changed, 61 insertions(+) >> >> diff --git a/Documentation/x86/resctrl.rst b/Documentation/x86/resctrl.rst >> index be443251b484..5aff8c2beb08 100644 >> --- a/Documentation/x86/resctrl.rst >> +++ b/Documentation/x86/resctrl.rst >> @@ -345,6 +345,14 @@ When control is enabled all CTRL_MON groups will also contain: >> file. On successful pseudo-locked region creation the mode will >> automatically change to "pseudo-locked". >> >> +"ctrl_hw_id": >> + Available only with debug option. On x86, reading this file shows >> + the Class of Service (CLOS) id which acts as a resource control >> + tag on which the resources can be throttled. Kernel assigns a new >> + CLOSID a control group is created depending on the available >> + CLOSIDs. Multiple cores(or threads) or processes can share a >> + same CLOSID in a resctrl group. > Please keep other content from the documentation in mind when making > this change. CLOSID is already documented, including the fact that it > is a limited resource. Please see content under: "Notes on cache occupancy > monitoring and control" where it, for example, states that "The number > of CLOSid and RMID are limited by the hardware." > > Considering this the above could just read: > "Available only with debug option. The identifier used by hardware > for the control group. On x86 this is the CLOSID." ok. Sure. > > Similar feedback to the "mon_hw_id" portion. Sure. Thanks Babu
Hi Babu, On 5/5/2023 2:45 PM, Moger, Babu wrote: > On 5/4/2023 2:04 PM, Reinette Chatre wrote: Thank you for trimming the header in replies. >> On 4/17/2023 4:34 PM, Babu Moger wrote: >>> When a user creates a control or monitor group, the CLOSID or RMID >>> are not visible to the user. It can help to debug the issues in some >>> cases. There are only available with "-o debug" option. >> Please see: Documentation/process/maintainer-tip.rst >> >> "It's also useful to structure the changelog into several paragraphs and not >> lump everything together into a single one. A good structure is to explain >> the context, the problem and the solution in separate paragraphs and this >> order." > ok Sure. >>> Add CLOSID(ctrl_hw_id) and RMID(mon_hw_id) to the control/monitor groups >> Please highlight that CLOSID and RMID are x86 concepts. > ok Sure. >> >>> display in resctrl interface. >>> $cat /sys/fs/resctrl/clos1/clos_hw_id >>> 1 >> This example does not match what the patch does (clos_hw_id -> ctrl_hw_id). > My bad. Will fix it. >> I also think this change would be more palatable (to non x86 audience) if >> the example resource group has a generic (non-x86 concept) name. > > ok. In this example the clos1 name sounds x86 specific. I can change it to ctrl_grp1. Hope this is what you meant. Yes, that is what I meant. ctrl_grp1 sounds good. Thank you Reinette
diff --git a/Documentation/x86/resctrl.rst b/Documentation/x86/resctrl.rst index be443251b484..5aff8c2beb08 100644 --- a/Documentation/x86/resctrl.rst +++ b/Documentation/x86/resctrl.rst @@ -345,6 +345,14 @@ When control is enabled all CTRL_MON groups will also contain: file. On successful pseudo-locked region creation the mode will automatically change to "pseudo-locked". +"ctrl_hw_id": + Available only with debug option. On x86, reading this file shows + the Class of Service (CLOS) id which acts as a resource control + tag on which the resources can be throttled. Kernel assigns a new + CLOSID a control group is created depending on the available + CLOSIDs. Multiple cores(or threads) or processes can share a + same CLOSID in a resctrl group. + When monitoring is enabled all MON groups will also contain: "mon_data": @@ -358,6 +366,15 @@ When monitoring is enabled all MON groups will also contain: the sum for all tasks in the CTRL_MON group and all tasks in MON groups. Please see example section for more details on usage. +"mon_hw_id": + Available only with debug option. On x86, reading this file shows + the Resource Monitoring ID (RMID) for monitoring the resource + utilization. Monitoring is performed by tagging each core (or + thread) or process via a RMID. Kernel assigns a new RMID when + a group is created depending on the available RMIDs. Multiple + cores (or threads) or processes can share a same RMID in a + resctrl group. + Resource allocation rules ------------------------- diff --git a/arch/x86/kernel/cpu/resctrl/rdtgroup.c b/arch/x86/kernel/cpu/resctrl/rdtgroup.c index 0169821bc08c..15ded0dd5b09 100644 --- a/arch/x86/kernel/cpu/resctrl/rdtgroup.c +++ b/arch/x86/kernel/cpu/resctrl/rdtgroup.c @@ -782,6 +782,38 @@ static int rdtgroup_tasks_show(struct kernfs_open_file *of, return ret; } +static int rdtgroup_closid_show(struct kernfs_open_file *of, + struct seq_file *s, void *v) +{ + struct rdtgroup *rdtgrp; + int ret = 0; + + rdtgrp = rdtgroup_kn_lock_live(of->kn); + if (rdtgrp) + seq_printf(s, "%u\n", rdtgrp->closid); + else + ret = -ENOENT; + rdtgroup_kn_unlock(of->kn); + + return ret; +} + +static int rdtgroup_rmid_show(struct kernfs_open_file *of, + struct seq_file *s, void *v) +{ + struct rdtgroup *rdtgrp; + int ret = 0; + + rdtgrp = rdtgroup_kn_lock_live(of->kn); + if (rdtgrp) + seq_printf(s, "%u\n", rdtgrp->mon.rmid); + else + ret = -ENOENT; + rdtgroup_kn_unlock(of->kn); + + return ret; +} + #ifdef CONFIG_PROC_CPU_RESCTRL /* @@ -1843,6 +1875,12 @@ static struct rftype res_common_files[] = { .seq_show = rdtgroup_tasks_show, .fflags = RFTYPE_BASE, }, + { + .name = "mon_hw_id", + .mode = 0444, + .kf_ops = &rdtgroup_kf_single_ops, + .seq_show = rdtgroup_rmid_show, + }, { .name = "schemata", .mode = 0644, @@ -1866,6 +1904,12 @@ static struct rftype res_common_files[] = { .seq_show = rdtgroup_size_show, .fflags = RFTYPE_CTRL_BASE, }, + { + .name = "ctrl_hw_id", + .mode = 0444, + .kf_ops = &rdtgroup_kf_single_ops, + .seq_show = rdtgroup_closid_show, + }, };