Message ID | 167278361325.34228.16916982678071203069.stgit@bmoger-ubuntu |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:4e01:0:0:0:0:0 with SMTP id p1csp4838087wrt; Tue, 3 Jan 2023 14:09:19 -0800 (PST) X-Google-Smtp-Source: AMrXdXs63anHclzB21GYvP6pcxFTey/41ilE7WP15QzIzn8YsEeIztR2qcOXHj/jpvB0LIwkebC/ X-Received: by 2002:a05:6a00:2a9:b0:581:f14:fde9 with SMTP id q9-20020a056a0002a900b005810f14fde9mr29731810pfs.16.1672783758935; Tue, 03 Jan 2023 14:09:18 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1672783758; cv=pass; d=google.com; s=arc-20160816; b=YQKpm/YysiJcGipkBvS3Tl0GMikQDTr6LX+2gXKTUpDvkdfODHv/tYvRxQ6xIAsNnF 3Unbnp3ohp/9+ycDj36876V0vL1L6/WnYiWFAbRo1nYPG7d8YawgFRj1kzmhlcYGpvnI UZ39STM983KxCnz5m0z0LsmdyCK06fJWZuTgdWyKVXnzt/x9qE23ThI3pl7XLRYHDR4+ CZ/MIuzSJTPyRUKP14n2/LkaCJKDhIEQTX8kjiExsHtsQOUMqNpUz+0933swbPRX6Gxh lcO+0FPIdluJKNnitiqJyo5+evBdT51Xd5D8HtcTt4DsW4eGSlpbq8t5FNBcBn43dO/J DE5g== 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=/7qtJrEoGp8AP6Vo7LCbs2EEQvG7I8yvIULPC360r3w=; b=vtyoAxLo+tw3jm3VEXCv53QVG6sijBByrBSrFC4Ca82YXIrY1UMNzceLA5uV/nJGbL LzP4bMJjUCsMOXQ+emflmPeExKGUHGIPlTvCKZTRrSud2mSdlcqPZasKnxIDX+cF7Hiq qUFjO4pOlyIllrdPjEYNHRek7BVH3RXgX2ulgv/SZPAIe/D1equ9Ch3SvpQkB5P981Dq l/bFe2nV2BEs3k+YOG7+lE7ptTJPOfge9/uRDwu+dQsrDaInfN8DlAZvErOSdlJXsgO2 iuGFAxf5Yh23GNyUVEnLEgxb05x7T2fr/OMXL66xHVniN8kTPcWF3F5gmFfzT1W4l+Qq q27A== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@amd.com header.s=selector1 header.b=hHASKWSD; 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 s5-20020a056a0008c500b005748eade34dsi36178599pfu.278.2023.01.03.14.09.06; Tue, 03 Jan 2023 14:09:18 -0800 (PST) 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=hHASKWSD; 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 S238581AbjACWHu (ORCPT <rfc822;tmhikaru@gmail.com> + 99 others); Tue, 3 Jan 2023 17:07:50 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37208 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238527AbjACWHK (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 3 Jan 2023 17:07:10 -0500 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10on2052.outbound.protection.outlook.com [40.107.92.52]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A487D15FED; Tue, 3 Jan 2023 14:07:04 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nPzJYiRuuHQpXNxujpGY89+LiQRfLvnczRqPxhKOPIka3zEku98MatPU/ampy9wOw8rVjTfGf5jHO2WTfZXS7ARM+qOrJGut7OC7BbTYkfDkF8KOxFxZ6QhSrPHCOfuKQkQyFlFKlxJGU9jExkGuToCqvYu99e2IRh5kc/iqSFP/7BcIkb/ttPPJT7FG8GaY5RexjOv+auQ6BO/FveAx5ojhsSIvvfIvNEzqFf1NUflixtqXDdFJMq1t229KKMo0MM0aHgtRT5JxIs3/6cVO14Qmwevvy+JQMzMzk6Vjl1TlSMma276GE0QFfCuqaqrBKiXn7EI9t5u3A0Vrq4ymXw== 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=/7qtJrEoGp8AP6Vo7LCbs2EEQvG7I8yvIULPC360r3w=; b=XcXYR1JXQ+QGrMFpgJ0gvTNKAg0h4EkNV3hECDxk7KHIvLZDe2xQrJUVUSfxJ3h8YfIEAKX7axOGQbS33mOUgtlVQZdWf/JSyxvAN+0CRFCBh9AoPpfmZvTebN5xVbmv0kIJaKBaC4FhcX9xaneP9ut6w9Ha12wCCplp+LrKRjCEvoZe2N80kbZ/RgqQJ5OHcC/mg6g0UXw2bWpw2/ySuOgQUtjrbLgkzAx3O9ex/0pwFTdFSaPGSYBjiVRcxBB9Pu//g0bzy3EaHlNIGivba397o8YqILK2e8AwtMRBW8xDXanQVpFztAJR5xK8DNxRKJw/tSyBaz11ckq+WwvreA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=linutronix.de 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=/7qtJrEoGp8AP6Vo7LCbs2EEQvG7I8yvIULPC360r3w=; b=hHASKWSDMiEvCkRCDj3wLHEdXJ6km+uY7a+PsiEWpKa3MMm8uOrWqDWVphpdMotmEoL5dgebo1ek6+FddhGgS4LyTRU03wymAtXKm2YBIoP/l+qY3KxG1lA9uSvA3DftYIBDRk3Tb1w0CN4ih9vMiQQq0dhhYsIt2Yx//2nS3D4= Received: from DM5PR07CA0106.namprd07.prod.outlook.com (2603:10b6:4:ae::35) by CH3PR12MB7523.namprd12.prod.outlook.com (2603:10b6:610:148::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5944.19; Tue, 3 Jan 2023 22:07:00 +0000 Received: from DS1PEPF0000E645.namprd02.prod.outlook.com (2603:10b6:4:ae:cafe::d3) by DM5PR07CA0106.outlook.office365.com (2603:10b6:4:ae::35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5966.19 via Frontend Transport; Tue, 3 Jan 2023 22:06:55 +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 DS1PEPF0000E645.mail.protection.outlook.com (10.167.17.203) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.5944.8 via Frontend Transport; Tue, 3 Jan 2023 22:06:55 +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; Tue, 3 Jan 2023 16:06:53 -0600 Subject: [RFC PATCH 3/3] x86/resctrl: Display the RMID and COSID for resctrl groups From: Babu Moger <babu.moger@amd.com> To: <fenghua.yu@intel.com>, <reinette.chatre@intel.com> CC: <tglx@linutronix.de>, <mingo@redhat.com>, <bp@alien8.de>, <dave.hansen@linux.intel.com>, <x86@kernel.org>, <hpa@zytor.com>, <corbet@lwn.net>, <linux-kernel@vger.kernel.org>, <linux-doc@vger.kernel.org>, <eranian@google.com>, <peternewman@google.com> Date: Tue, 3 Jan 2023 16:06:53 -0600 Message-ID: <167278361325.34228.16916982678071203069.stgit@bmoger-ubuntu> In-Reply-To: <167278351577.34228.12803395505584557101.stgit@bmoger-ubuntu> References: <167278351577.34228.12803395505584557101.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: DS1PEPF0000E645:EE_|CH3PR12MB7523:EE_ X-MS-Office365-Filtering-Correlation-Id: 0311d435-4be1-497f-e124-08daedd6d35a X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 7qkIw5T0LQwSF8QI9+Qw4aDPkRsFHAEauFugseDkLZNvVc/tR/xBQ8ov6Jk1puzGkWiOD5/ZvGJzQAznsLPgwrHdRQsZ70ikPnSvwUFqRQBeZI+nyWA9v7D7rX0wra5bkOrwSulDq1rGN6w36mF/aQDK2TwU7KkBy6ATLoaJPbZwZzzt68Kp2JePQ9vdioPlfacH1CnCkX4b04tHzFNuhYsqZJqGTguM5Us071qT8vskkZaPKANZShDx//eVxLTfr4nqV7faHmRPmOjclavUnPU0sNOosEi4+tPadX7pVQWYbfdOI/Mk9HKQOEOawyzR3M2bEIqxS/Md7qVE4URaIbPQskZ+LuZT1AUa2zr8uRgyyRTzPU//S+C+vKwhkTWjgmF4j+T9mZuGM9w6KoWl0tTeCL7J1jbd5uuRdiwuTzgiua1GHno02JNlkRkZu94Rrgkg3XUntyc62SvxUf5DA+3bHYfrHorr94MFEbcYm1Q7y84GvTZJVQtCbsbt8h6cUmIxTswojLLms3h7F379w6UPEj8Dklg5Mv4ZA8pcbegQLr6CO26yyDZekjmb9aVOG+0ZOZUrSa9uXxvKz0wFWSBUiIE1l1R8wUIc1gAE4hBEF7iEwBElkRZOJK2RjhPuYfZgheuQh5tiR3qFlNhK8dkSR0Qkt3vpkkFD04yFbvmyhjfGzesELRVUpkDeMu5lDL6Wlzu4pC2n8QfoemsZNOCzMBAiy/ng8UpKk/E2FSlm6G4QE8r6dElRkYGC3RVeK8VUgjJ7ECZ9mHm93S0u03TGpVuYD8C29Fhy63SiHgU= 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:(13230022)(4636009)(7916004)(376002)(346002)(136003)(39860400002)(396003)(451199015)(36840700001)(46966006)(40470700004)(83380400001)(47076005)(426003)(16526019)(336012)(26005)(9686003)(82310400005)(33716001)(103116003)(40480700001)(40460700003)(86362001)(36860700001)(81166007)(82740400003)(356005)(186003)(478600001)(41300700001)(8676002)(4326008)(2906002)(7416002)(5660300002)(8936002)(44832011)(16576012)(316002)(70586007)(70206006)(54906003)(110136005)(22166009)(71626007)(36900700001);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Jan 2023 22:06:55.0297 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 0311d435-4be1-497f-e124-08daedd6d35a 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: DS1PEPF0000E645.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB7523 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS 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: <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?1754040903218220483?= X-GMAIL-MSGID: =?utf-8?q?1754040903218220483?= |
Series |
x86/resctrl: Miscellaneous resctrl features
|
|
Commit Message
Moger, Babu
Jan. 3, 2023, 10:06 p.m. UTC
When a user creates a control or monitor group, the CLOSID or RMID
are not visible to the user. These are architecturally defined entities.
There is no harm in displaying these in resctrl groups. Sometimes it
can help to debug the issues.
Add CLOSID and RMID to the control/monitor groups display in resctrl
interface.
$cat /sys/fs/resctrl/clos1/closid
1
$cat /sys/fs/resctrl/mon_groups/mon1/rmid
3
Signed-off-by: Babu Moger <babu.moger@amd.com>
---
Documentation/x86/resctrl.rst | 15 ++++++++++
arch/x86/kernel/cpu/resctrl/rdtgroup.c | 46 ++++++++++++++++++++++++++++++++
2 files changed, 61 insertions(+)
Comments
Hi, Babu, > When a user creates a control or monitor group, the CLOSID or RMID are not > visible to the user. These are architecturally defined entities. > There is no harm in displaying these in resctrl groups. Sometimes it can help to > debug the issues. Although "no harm" to show them, it's not useful for generic user either and may cause confusion sometimes. CLOSID and RMID are supposed to be invisible to generic users. Maybe introduce a new resctrl mount option called "debug" and show the files and maybe other future debug info only in debug mode? > > Add CLOSID and RMID to the control/monitor groups display in resctrl interface. > > $cat /sys/fs/resctrl/clos1/closid > 1 > $cat /sys/fs/resctrl/mon_groups/mon1/rmid > 3 > > Signed-off-by: Babu Moger <babu.moger@amd.com> > --- > Documentation/x86/resctrl.rst | 15 ++++++++++ > arch/x86/kernel/cpu/resctrl/rdtgroup.c | 46 > ++++++++++++++++++++++++++++++++ > 2 files changed, 61 insertions(+) > > diff --git a/Documentation/x86/resctrl.rst b/Documentation/x86/resctrl.rst > index f26e16412bcb..8520514bc8b5 100644 > --- a/Documentation/x86/resctrl.rst > +++ b/Documentation/x86/resctrl.rst > @@ -231,6 +231,14 @@ All groups contain the following files: > Just like "cpus", only using ranges of CPUs instead of bitmasks. > > > +"rmid": > + 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 Resource Monitoring > + ID (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 domain. > + > When control is enabled all CTRL_MON groups will also contain: > > "schemata": > @@ -252,6 +260,13 @@ 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". > > +"closid": > + 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 domain. > + > When monitoring is enabled all MON groups will also contain: > > "mon_data": > diff --git a/arch/x86/kernel/cpu/resctrl/rdtgroup.c > b/arch/x86/kernel/cpu/resctrl/rdtgroup.c > index 0d71ed22cfa9..98b4798e5cae 100644 > --- a/arch/x86/kernel/cpu/resctrl/rdtgroup.c > +++ b/arch/x86/kernel/cpu/resctrl/rdtgroup.c > @@ -769,6 +769,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 > > /* > @@ -1593,6 +1625,20 @@ static struct rftype res_common_files[] = { > .seq_show = rdtgroup_size_show, > .fflags = RF_CTRL_BASE, > }, > + { > + .name = "closid", > + .mode = 0444, > + .kf_ops = &rdtgroup_kf_single_ops, > + .seq_show = rdtgroup_closid_show, > + .fflags = RF_CTRL_BASE, > + }, > + { > + .name = "rmid", > + .mode = 0444, > + .kf_ops = &rdtgroup_kf_single_ops, > + .seq_show = rdtgroup_rmid_show, > + .fflags = RFTYPE_BASE, > + }, > > }; > > Thanks. -Fenghua
On Tue, Jan 3, 2023 at 10:06 PM Yu, Fenghua <fenghua.yu@intel.com> wrote: > > Hi, Babu, > > > When a user creates a control or monitor group, the CLOSID or RMID are not > > visible to the user. These are architecturally defined entities. > > There is no harm in displaying these in resctrl groups. Sometimes it can help to > > debug the issues. > Although "no harm" to show them, it's not useful for generic user either and may > cause confusion sometimes. CLOSID and RMID are supposed to be invisible to > generic users. > > Maybe introduce a new resctrl mount option called "debug" and show the files > and maybe other future debug info only in debug mode? > On other non-x86 architectures, these have no meaning or no direct mapping. Take ARM MPAM, it is called PARTID and it does not map to either RMID or CLOSID, it is combined. Why would you call this closid/rmid at the user level? You could instead use a more generic name such as mon_hw_id, ctrl_hw_id. And on ARM they would be the same. Just my suggestion. > > > > > Add CLOSID and RMID to the control/monitor groups display in resctrl interface. > > > > $cat /sys/fs/resctrl/clos1/closid > > 1 > > $cat /sys/fs/resctrl/mon_groups/mon1/rmid > > 3 > > > > Signed-off-by: Babu Moger <babu.moger@amd.com> > > --- > > Documentation/x86/resctrl.rst | 15 ++++++++++ > > arch/x86/kernel/cpu/resctrl/rdtgroup.c | 46 > > ++++++++++++++++++++++++++++++++ > > 2 files changed, 61 insertions(+) > > > > diff --git a/Documentation/x86/resctrl.rst b/Documentation/x86/resctrl.rst > > index f26e16412bcb..8520514bc8b5 100644 > > --- a/Documentation/x86/resctrl.rst > > +++ b/Documentation/x86/resctrl.rst > > @@ -231,6 +231,14 @@ All groups contain the following files: > > Just like "cpus", only using ranges of CPUs instead of bitmasks. > > > > > > +"rmid": > > + 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 Resource Monitoring > > + ID (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 domain. > > + > > When control is enabled all CTRL_MON groups will also contain: > > > > "schemata": > > @@ -252,6 +260,13 @@ 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". > > > > +"closid": > > + 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 domain. > > + > > When monitoring is enabled all MON groups will also contain: > > > > "mon_data": > > diff --git a/arch/x86/kernel/cpu/resctrl/rdtgroup.c > > b/arch/x86/kernel/cpu/resctrl/rdtgroup.c > > index 0d71ed22cfa9..98b4798e5cae 100644 > > --- a/arch/x86/kernel/cpu/resctrl/rdtgroup.c > > +++ b/arch/x86/kernel/cpu/resctrl/rdtgroup.c > > @@ -769,6 +769,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 > > > > /* > > @@ -1593,6 +1625,20 @@ static struct rftype res_common_files[] = { > > .seq_show = rdtgroup_size_show, > > .fflags = RF_CTRL_BASE, > > }, > > + { > > + .name = "closid", > > + .mode = 0444, > > + .kf_ops = &rdtgroup_kf_single_ops, > > + .seq_show = rdtgroup_closid_show, > > + .fflags = RF_CTRL_BASE, > > + }, > > + { > > + .name = "rmid", > > + .mode = 0444, > > + .kf_ops = &rdtgroup_kf_single_ops, > > + .seq_show = rdtgroup_rmid_show, > > + .fflags = RFTYPE_BASE, > > + }, > > > > }; > > > > > Thanks. > > -Fenghua
Hi Fenghua, On 1/4/23 00:06, Yu, Fenghua wrote: > Hi, Babu, > >> When a user creates a control or monitor group, the CLOSID or RMID are not >> visible to the user. These are architecturally defined entities. >> There is no harm in displaying these in resctrl groups. Sometimes it can help to >> debug the issues. > Although "no harm" to show them, it's not useful for generic user either and may > cause confusion sometimes. CLOSID and RMID are supposed to be invisible to > generic users. > > Maybe introduce a new resctrl mount option called "debug" and show the files > and maybe other future debug info only in debug mode? Actually, test team feels very strongly about this. Whenever there is some issue, first question is what is the rmid or closid are you running on? We normally don't have an answer for that. In my opinion, adding debug mode just for these two fields seems way overkill. Thanks Babu > >> Add CLOSID and RMID to the control/monitor groups display in resctrl interface. >> >> $cat /sys/fs/resctrl/clos1/closid >> 1 >> $cat /sys/fs/resctrl/mon_groups/mon1/rmid >> 3 >> >> Signed-off-by: Babu Moger <babu.moger@amd.com> >> --- >> Documentation/x86/resctrl.rst | 15 ++++++++++ >> arch/x86/kernel/cpu/resctrl/rdtgroup.c | 46 >> ++++++++++++++++++++++++++++++++ >> 2 files changed, 61 insertions(+) >> >> diff --git a/Documentation/x86/resctrl.rst b/Documentation/x86/resctrl.rst >> index f26e16412bcb..8520514bc8b5 100644 >> --- a/Documentation/x86/resctrl.rst >> +++ b/Documentation/x86/resctrl.rst >> @@ -231,6 +231,14 @@ All groups contain the following files: >> Just like "cpus", only using ranges of CPUs instead of bitmasks. >> >> >> +"rmid": >> + 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 Resource Monitoring >> + ID (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 domain. >> + >> When control is enabled all CTRL_MON groups will also contain: >> >> "schemata": >> @@ -252,6 +260,13 @@ 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". >> >> +"closid": >> + 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 domain. >> + >> When monitoring is enabled all MON groups will also contain: >> >> "mon_data": >> diff --git a/arch/x86/kernel/cpu/resctrl/rdtgroup.c >> b/arch/x86/kernel/cpu/resctrl/rdtgroup.c >> index 0d71ed22cfa9..98b4798e5cae 100644 >> --- a/arch/x86/kernel/cpu/resctrl/rdtgroup.c >> +++ b/arch/x86/kernel/cpu/resctrl/rdtgroup.c >> @@ -769,6 +769,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 >> >> /* >> @@ -1593,6 +1625,20 @@ static struct rftype res_common_files[] = { >> .seq_show = rdtgroup_size_show, >> .fflags = RF_CTRL_BASE, >> }, >> + { >> + .name = "closid", >> + .mode = 0444, >> + .kf_ops = &rdtgroup_kf_single_ops, >> + .seq_show = rdtgroup_closid_show, >> + .fflags = RF_CTRL_BASE, >> + }, >> + { >> + .name = "rmid", >> + .mode = 0444, >> + .kf_ops = &rdtgroup_kf_single_ops, >> + .seq_show = rdtgroup_rmid_show, >> + .fflags = RFTYPE_BASE, >> + }, >> >> }; >> >> > Thanks. > > -Fenghua
Hi Stephane, On 1/4/23 00:45, Stephane Eranian wrote: > On Tue, Jan 3, 2023 at 10:06 PM Yu, Fenghua <fenghua.yu@intel.com> wrote: >> Hi, Babu, >> >>> When a user creates a control or monitor group, the CLOSID or RMID are not >>> visible to the user. These are architecturally defined entities. >>> There is no harm in displaying these in resctrl groups. Sometimes it can help to >>> debug the issues. >> Although "no harm" to show them, it's not useful for generic user either and may >> cause confusion sometimes. CLOSID and RMID are supposed to be invisible to >> generic users. >> >> Maybe introduce a new resctrl mount option called "debug" and show the files >> and maybe other future debug info only in debug mode? >> > On other non-x86 architectures, these have no meaning or no direct mapping. > Take ARM MPAM, it is called PARTID and it does not map to either RMID > or CLOSID, it is combined. > Why would you call this closid/rmid at the user level? > You could instead use a more generic name such as mon_hw_id, > ctrl_hw_id. And on ARM they would be the same. > Just my suggestion. Sure. We can change the names to mon_hw_id and ctrl_hw_id. Thanks Babu > > >>> Add CLOSID and RMID to the control/monitor groups display in resctrl interface. >>> >>> $cat /sys/fs/resctrl/clos1/closid >>> 1 >>> $cat /sys/fs/resctrl/mon_groups/mon1/rmid >>> 3 >>> >>> Signed-off-by: Babu Moger <babu.moger@amd.com> >>> --- >>> Documentation/x86/resctrl.rst | 15 ++++++++++ >>> arch/x86/kernel/cpu/resctrl/rdtgroup.c | 46 >>> ++++++++++++++++++++++++++++++++ >>> 2 files changed, 61 insertions(+) >>> >>> diff --git a/Documentation/x86/resctrl.rst b/Documentation/x86/resctrl.rst >>> index f26e16412bcb..8520514bc8b5 100644 >>> --- a/Documentation/x86/resctrl.rst >>> +++ b/Documentation/x86/resctrl.rst >>> @@ -231,6 +231,14 @@ All groups contain the following files: >>> Just like "cpus", only using ranges of CPUs instead of bitmasks. >>> >>> >>> +"rmid": >>> + 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 Resource Monitoring >>> + ID (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 domain. >>> + >>> When control is enabled all CTRL_MON groups will also contain: >>> >>> "schemata": >>> @@ -252,6 +260,13 @@ 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". >>> >>> +"closid": >>> + 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 domain. >>> + >>> When monitoring is enabled all MON groups will also contain: >>> >>> "mon_data": >>> diff --git a/arch/x86/kernel/cpu/resctrl/rdtgroup.c >>> b/arch/x86/kernel/cpu/resctrl/rdtgroup.c >>> index 0d71ed22cfa9..98b4798e5cae 100644 >>> --- a/arch/x86/kernel/cpu/resctrl/rdtgroup.c >>> +++ b/arch/x86/kernel/cpu/resctrl/rdtgroup.c >>> @@ -769,6 +769,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 >>> >>> /* >>> @@ -1593,6 +1625,20 @@ static struct rftype res_common_files[] = { >>> .seq_show = rdtgroup_size_show, >>> .fflags = RF_CTRL_BASE, >>> }, >>> + { >>> + .name = "closid", >>> + .mode = 0444, >>> + .kf_ops = &rdtgroup_kf_single_ops, >>> + .seq_show = rdtgroup_closid_show, >>> + .fflags = RF_CTRL_BASE, >>> + }, >>> + { >>> + .name = "rmid", >>> + .mode = 0444, >>> + .kf_ops = &rdtgroup_kf_single_ops, >>> + .seq_show = rdtgroup_rmid_show, >>> + .fflags = RFTYPE_BASE, >>> + }, >>> >>> }; >>> >>> >> Thanks. >> >> -Fenghua
Hi, Babu, > >> When a user creates a control or monitor group, the CLOSID or RMID > >> are not visible to the user. These are architecturally defined entities. > >> There is no harm in displaying these in resctrl groups. Sometimes it > >> can help to debug the issues. > > Although "no harm" to show them, it's not useful for generic user > > either and may cause confusion sometimes. CLOSID and RMID are supposed > > to be invisible to generic users. > > > > Maybe introduce a new resctrl mount option called "debug" and show the > > files and maybe other future debug info only in debug mode? > > Actually, test team feels very strongly about this. Whenever there is some issue, > first question is what is the rmid or closid are you running on? We normally don't > have an answer for that. > > In my opinion, adding debug mode just for these two fields seems way overkill. Yes, they are useful for "test team" (quoted from your statement) and developers. Not for end users. A debug mode is useful not just for these two files. I'm working on another resctrl project where much more complex hardware info needs to be dumped for debug purpose only. It's obvious not to show it in generic use. It's more obvious to just show the info file in debug mode in my case. I think these CLOSID and RMID files and future debug files belong to a new debug mode. It would be better to introduce the debug mode now rather than later so that it can be extended easily in the future. Maybe we can enable debug mode in a separate debug mode patch: 1. Add RFTYPE_DEBUG as a new file type. Files with this flag are for debug purpose and only be visible in\ debug mode. 2. Add RFTYPE_INVISIBLE as a new file type. Files with this flag will be invisible/not be added in resctrl fs. 3. Add mount parameter "debug" so that ctx->debug=true if mount -o debug is given. 4. If ctx->debug is true, in rdt_enable_ctx(), go through RFTYPE_DEBUG files in res_common_files[] and mark fflags with RFTYPE_INVISIBLE. 5. In rdtgroup_add_file(), if (rft->fflags & RFTYPE_INVISIBLE) return. So the debug files will be visible only in debug mode. With the debug mode patch in place, it's simple to extend to any debug files: In your case, update this patch by just adding RFTYPE_DEBUG in fflags. Then the debug mode will work for this patch automatically. In my case or any future debug files, we just simply add RFTYPE_DEBUG in fflags and the debug mode will work automatically. Does it make sense? Thanks. -Fenghua
Hi Fenghua, On 1/4/23 17:54, Yu, Fenghua wrote: > Hi, Babu, > >>>> When a user creates a control or monitor group, the CLOSID or RMID >>>> are not visible to the user. These are architecturally defined entities. >>>> There is no harm in displaying these in resctrl groups. Sometimes it >>>> can help to debug the issues. >>> Although "no harm" to show them, it's not useful for generic user >>> either and may cause confusion sometimes. CLOSID and RMID are supposed >>> to be invisible to generic users. >>> >>> Maybe introduce a new resctrl mount option called "debug" and show the >>> files and maybe other future debug info only in debug mode? >> Actually, test team feels very strongly about this. Whenever there is some issue, >> first question is what is the rmid or closid are you running on? We normally don't >> have an answer for that. >> >> In my opinion, adding debug mode just for these two fields seems way overkill. > Yes, they are useful for "test team" (quoted from your statement) and developers. > Not for end users. > > A debug mode is useful not just for these two files. I'm working on another resctrl > project where much more complex hardware info needs to be dumped for debug purpose > only. It's obvious not to show it in generic use. It's more obvious to just show the info file in > debug mode in my case. > > I think these CLOSID and RMID files and future debug files belong to a new debug mode. > It would be better to introduce the debug mode now rather than later so that it can be extended > easily in the future. > > Maybe we can enable debug mode in a separate debug mode patch: > 1. Add RFTYPE_DEBUG as a new file type. Files with this flag are for debug purpose and only be visible in\ > debug mode. > 2. Add RFTYPE_INVISIBLE as a new file type. Files with this flag will be invisible/not be added in resctrl fs. > 3. Add mount parameter "debug" so that ctx->debug=true if mount -o debug is given. > 4. If ctx->debug is true, in rdt_enable_ctx(), go through RFTYPE_DEBUG files in res_common_files[] and mark > fflags with RFTYPE_INVISIBLE. > 5. In rdtgroup_add_file(), if (rft->fflags & RFTYPE_INVISIBLE) return. So the debug files will be visible only > in debug mode. > > With the debug mode patch in place, it's simple to extend to any debug files: > In your case, update this patch by just adding RFTYPE_DEBUG in fflags. Then the debug mode will work > for this patch automatically. > In my case or any future debug files, we just simply add RFTYPE_DEBUG in fflags and the debug mode will > work automatically. > > Does it make sense? Yes. Sure. The debug mode needs to be resctrl mount option. I will take a look at this further to see what can be done. Thanks Babu
diff --git a/Documentation/x86/resctrl.rst b/Documentation/x86/resctrl.rst index f26e16412bcb..8520514bc8b5 100644 --- a/Documentation/x86/resctrl.rst +++ b/Documentation/x86/resctrl.rst @@ -231,6 +231,14 @@ All groups contain the following files: Just like "cpus", only using ranges of CPUs instead of bitmasks. +"rmid": + 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 Resource Monitoring + ID (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 domain. + When control is enabled all CTRL_MON groups will also contain: "schemata": @@ -252,6 +260,13 @@ 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". +"closid": + 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 domain. + When monitoring is enabled all MON groups will also contain: "mon_data": diff --git a/arch/x86/kernel/cpu/resctrl/rdtgroup.c b/arch/x86/kernel/cpu/resctrl/rdtgroup.c index 0d71ed22cfa9..98b4798e5cae 100644 --- a/arch/x86/kernel/cpu/resctrl/rdtgroup.c +++ b/arch/x86/kernel/cpu/resctrl/rdtgroup.c @@ -769,6 +769,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 /* @@ -1593,6 +1625,20 @@ static struct rftype res_common_files[] = { .seq_show = rdtgroup_size_show, .fflags = RF_CTRL_BASE, }, + { + .name = "closid", + .mode = 0444, + .kf_ops = &rdtgroup_kf_single_ops, + .seq_show = rdtgroup_closid_show, + .fflags = RF_CTRL_BASE, + }, + { + .name = "rmid", + .mode = 0444, + .kf_ops = &rdtgroup_kf_single_ops, + .seq_show = rdtgroup_rmid_show, + .fflags = RFTYPE_BASE, + }, };