From nobody Sun Sep 14 07:53:02 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id F2D26C77B73 for ; Wed, 19 Apr 2023 12:50:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233119AbjDSMuz (ORCPT ); Wed, 19 Apr 2023 08:50:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34322 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232992AbjDSMuv (ORCPT ); Wed, 19 Apr 2023 08:50:51 -0400 Received: from mail-yw1-x114a.google.com (mail-yw1-x114a.google.com [IPv6:2607:f8b0:4864:20::114a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 79EB96EAD for ; Wed, 19 Apr 2023 05:50:41 -0700 (PDT) Received: by mail-yw1-x114a.google.com with SMTP id 00721157ae682-54fde069e4aso133812847b3.3 for ; Wed, 19 Apr 2023 05:50:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1681908640; x=1684500640; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=M55eRuHQJrupxqsaP770qxmiyWjSxTprBCDKIWruVU8=; b=LXjy63dN+KA/a+ihM+Hvrk/noXBuUo93Q35thIox5tSdDL2o71/NMZqFSYRW0EBM4P EFX9I9zPzMnxSNaBMaLHxoq+qKvEcsWsmeEXD3h2XX8VP1TN70UUtZrcF025i79nZDqa VYi1WpoKBj5pu+akQ/sWrJLnII87r+R3KLUmrXRQRQY92oMrME3VBmxN7sElDqCBoWrx lXo+oopgXDC+bwQHMXVYMf3RRHvxlbwsNLPAsX5CrT4gmHs2cj/cjZhAZINSVAWMoNCH n+pDViYF29j82CWSRE3IgGrfv302KxrSw7qSMoOyeUOz03lZl110Yp6DcbGXZyKaYWi0 XLZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681908640; x=1684500640; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=M55eRuHQJrupxqsaP770qxmiyWjSxTprBCDKIWruVU8=; b=IrvAPAUWWjfKV2APoqSn9/F+gIDeCIR3qKbb4e07tPYzvZeEdZrq9e1A//r8ue0P8a kpa1oKGQ1N4yWVa/bW98gxZWfnRJo3dRpAhyM9HZSBB8rrc5QeUYiCLEZJEwxMH4gld/ FhAJT1Zz8Qbfp5OH1UjJQGaULcpMlxn7ccWTqVMWZutJf2ZRdyPOGCujWj5w70BAJSFq N1NhIagVcMveGmq7OyoyUaYRektHbUpcuV2pD8/auCuByJlyfNUu3lmDBZ6qexEIBs+T WmZWHxf6ZEKD8DZFMUSEhePcxfK10jx/zeft3h1j4W8PGmK8UC0/WmoDjogizPryeLhr JjdA== X-Gm-Message-State: AAQBX9e8vaVuvay+Lj8zQ/RvRCcGUg1kk37x7GBu0OKBppwnij0SYRbd D1pxbbIT06v8m5dtDosqqfla2D7seuN+D/j3Pg== X-Google-Smtp-Source: AKy350bHCu6N/9gE0Xr0AQjCLyCYOOOEiAnM+qBQM/oKHnm8lOsLRsxUyXnZgd1futy7TWNiA6JxT/4GV9CrMcsl6A== X-Received: from peternewman0.zrh.corp.google.com ([2a00:79e0:9d:6:b36e:a25e:826d:b66a]) (user=peternewman job=sendgmr) by 2002:a25:c245:0:b0:997:c919:4484 with SMTP id s66-20020a25c245000000b00997c9194484mr11392762ybf.6.1681908640818; Wed, 19 Apr 2023 05:50:40 -0700 (PDT) Date: Wed, 19 Apr 2023 14:50:13 +0200 In-Reply-To: <20230419125015.693566-1-peternewman@google.com> Mime-Version: 1.0 References: <20230419125015.693566-1-peternewman@google.com> X-Mailer: git-send-email 2.40.0.634.g4ca3ef3211-goog Message-ID: <20230419125015.693566-2-peternewman@google.com> Subject: [PATCH v6 1/3] x86/resctrl: Factor rdtgroup lock for multi-file ops From: Peter Newman To: fenghua.yu@intel.com, reinette.chatre@intel.com Cc: Babu.Moger@amd.com, bp@alien8.de, dave.hansen@linux.intel.com, eranian@google.com, gupasani@google.com, hpa@zytor.com, james.morse@arm.com, linux-kernel@vger.kernel.org, mingo@redhat.com, skodak@google.com, tglx@linutronix.de, tony.luck@intel.com, x86@kernel.org, Peter Newman Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" rdtgroup_kn_lock_live() can only release a kernfs reference for a single file before waiting on the rdtgroup_mutex, limiting its usefulness for operations on multiple files, such as rename. Factor the work needed to respectively break and unbreak active protection on an individual file into rdtgroup_kn_{get,put}(). No functional change. Signed-off-by: Peter Newman Reviewed-by: Reinette Chatre Tested-by: Babu Moger --- arch/x86/kernel/cpu/resctrl/rdtgroup.c | 35 ++++++++++++++++---------- 1 file changed, 22 insertions(+), 13 deletions(-) diff --git a/arch/x86/kernel/cpu/resctrl/rdtgroup.c b/arch/x86/kernel/cpu/r= esctrl/rdtgroup.c index 6ad33f355861..51b869149e76 100644 --- a/arch/x86/kernel/cpu/resctrl/rdtgroup.c +++ b/arch/x86/kernel/cpu/resctrl/rdtgroup.c @@ -2301,6 +2301,26 @@ static struct rdtgroup *kernfs_to_rdtgroup(struct ke= rnfs_node *kn) } } =20 +static void rdtgroup_kn_get(struct rdtgroup *rdtgrp, struct kernfs_node *k= n) +{ + atomic_inc(&rdtgrp->waitcount); + kernfs_break_active_protection(kn); +} + +static void rdtgroup_kn_put(struct rdtgroup *rdtgrp, struct kernfs_node *k= n) +{ + if (atomic_dec_and_test(&rdtgrp->waitcount) && + (rdtgrp->flags & RDT_DELETED)) { + if (rdtgrp->mode =3D=3D RDT_MODE_PSEUDO_LOCKSETUP || + rdtgrp->mode =3D=3D RDT_MODE_PSEUDO_LOCKED) + rdtgroup_pseudo_lock_remove(rdtgrp); + kernfs_unbreak_active_protection(kn); + rdtgroup_remove(rdtgrp); + } else { + kernfs_unbreak_active_protection(kn); + } +} + struct rdtgroup *rdtgroup_kn_lock_live(struct kernfs_node *kn) { struct rdtgroup *rdtgrp =3D kernfs_to_rdtgroup(kn); @@ -2308,8 +2328,7 @@ struct rdtgroup *rdtgroup_kn_lock_live(struct kernfs_= node *kn) if (!rdtgrp) return NULL; =20 - atomic_inc(&rdtgrp->waitcount); - kernfs_break_active_protection(kn); + rdtgroup_kn_get(rdtgrp, kn); =20 mutex_lock(&rdtgroup_mutex); =20 @@ -2328,17 +2347,7 @@ void rdtgroup_kn_unlock(struct kernfs_node *kn) return; =20 mutex_unlock(&rdtgroup_mutex); - - if (atomic_dec_and_test(&rdtgrp->waitcount) && - (rdtgrp->flags & RDT_DELETED)) { - if (rdtgrp->mode =3D=3D RDT_MODE_PSEUDO_LOCKSETUP || - rdtgrp->mode =3D=3D RDT_MODE_PSEUDO_LOCKED) - rdtgroup_pseudo_lock_remove(rdtgrp); - kernfs_unbreak_active_protection(kn); - rdtgroup_remove(rdtgrp); - } else { - kernfs_unbreak_active_protection(kn); - } + rdtgroup_kn_put(rdtgrp, kn); } =20 static int mkdir_mondata_all(struct kernfs_node *parent_kn, --=20 2.40.0.634.g4ca3ef3211-goog From nobody Sun Sep 14 07:53:02 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 13D38C77B73 for ; Wed, 19 Apr 2023 12:51:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233165AbjDSMu7 (ORCPT ); Wed, 19 Apr 2023 08:50:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34340 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232869AbjDSMux (ORCPT ); Wed, 19 Apr 2023 08:50:53 -0400 Received: from mail-yb1-xb49.google.com (mail-yb1-xb49.google.com [IPv6:2607:f8b0:4864:20::b49]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8F1657695 for ; Wed, 19 Apr 2023 05:50:44 -0700 (PDT) Received: by mail-yb1-xb49.google.com with SMTP id l124-20020a252582000000b00b8f5572bcdaso15868733ybl.13 for ; Wed, 19 Apr 2023 05:50:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1681908643; x=1684500643; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=2VyinE+DDb/Q7Dr6L/ZifSAtwYa3P2xEDwWdnlneadk=; b=svjbIScMa28a4IqxeHSqZo7K9kjy2RdzU5ujfVKTAYQVvPZ9WYuAEpj3wnPqI9Srys YkqpOPCSqFQqVkLJ9eb8xlsqXM3qc5Y3GY8rGcXXHjyO+VxGuahJadcWV0aAnz9N1XtA 6PuDQdV6eyq1DjZqy62QFRJ1pu+RAQqjQF73JkhPovFBaVddJ3wf9r5hVxvICinyyUnV 9fpEHLxOWGIWVueEQRRKTp6F/M2zYS96qDGPYYezWJv0X8fwiZcWnhyyBkjCTYXogWPM SbXnWPh7SNOpOEN8qXdsDUIkMlXCOzSuFO2IYKtgtIndj19fiZrVvfDRog2H/uBBzOkw WejA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681908643; x=1684500643; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=2VyinE+DDb/Q7Dr6L/ZifSAtwYa3P2xEDwWdnlneadk=; b=C1PGVzwwgpav7/+df+D8A/VnOOEkqr9GaC0/gQqskEkhBNXDjuwa8e+J8779PPqk4S BuY7j/tWcNSbpfjX3Ab7UN5SgIsmOmcxYTnQiC3BIZlEbDrBFGLPxRewC+XT3AXqhclb XzBAZ/AV1w1n1U32p/ojwRDIyxEcApns2fWHn4w+vny9L8f0UbcQtGCx7MPyg3nsN0yu v5+Pm1ufRyRNmh91ElmUoe5m8nas7Ih3IVPG8gtlk4KLWi8nh3gzyubDvPsOaTb3DH1T KUWSzem4CTCNEop2jbykt7KMppSc8J032E0saXkkNij3CCyrc+rDPikCEQESpA63tdXO b2NA== X-Gm-Message-State: AAQBX9fTiQrkKIzR4DQGhnEq7vFoSPQvM6efmVqQp1CJjHqwX+qhvngR RbPHA5GbkKCPJnKNqVUiiKIys6bwFJwde01UqA== X-Google-Smtp-Source: AKy350ah+3rcWggCw0Iac5AVviXz9FaXW80vFYRnXbjCS4N8chgJDgp6D08LYnwHnek2bboP9DUm5T4VgBShDZbFBg== X-Received: from peternewman0.zrh.corp.google.com ([2a00:79e0:9d:6:b36e:a25e:826d:b66a]) (user=peternewman job=sendgmr) by 2002:a25:d1cc:0:b0:b95:65ad:4399 with SMTP id i195-20020a25d1cc000000b00b9565ad4399mr2913072ybg.8.1681908643819; Wed, 19 Apr 2023 05:50:43 -0700 (PDT) Date: Wed, 19 Apr 2023 14:50:14 +0200 In-Reply-To: <20230419125015.693566-1-peternewman@google.com> Mime-Version: 1.0 References: <20230419125015.693566-1-peternewman@google.com> X-Mailer: git-send-email 2.40.0.634.g4ca3ef3211-goog Message-ID: <20230419125015.693566-3-peternewman@google.com> Subject: [PATCH v6 2/3] x86/resctrl: Implement rename op for mon groups From: Peter Newman To: fenghua.yu@intel.com, reinette.chatre@intel.com Cc: Babu.Moger@amd.com, bp@alien8.de, dave.hansen@linux.intel.com, eranian@google.com, gupasani@google.com, hpa@zytor.com, james.morse@arm.com, linux-kernel@vger.kernel.org, mingo@redhat.com, skodak@google.com, tglx@linutronix.de, tony.luck@intel.com, x86@kernel.org, Peter Newman Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" To change the resources allocated to a large group of tasks, such as an application container, a container manager must write all of the tasks' IDs into the tasks file interface of the new control group. This is challenging when the container's task list is always changing. In addition, if the container manager is using monitoring groups to separately track the bandwidth of containers assigned to the same control group, when moving a container, it must first move the container's tasks to the default monitoring group of the new control group before it can move these tasks into the container's replacement monitoring group under the destination control group. This is undesirable because it makes bandwidth usage during the move unattributable to the correct tasks and resets monitoring event counters and cache usage information for the group. Implement the rename operation only for resctrlfs monitor groups to enable users to move a monitoring group from one control group to another. This effects a change in resources allocated to all the tasks in the monitoring group while otherwise leaving the monitoring data intact. Signed-off-by: Peter Newman Reviewed-by: Reinette Chatre Tested-by: Babu Moger --- arch/x86/kernel/cpu/resctrl/rdtgroup.c | 128 +++++++++++++++++++++++++ 1 file changed, 128 insertions(+) diff --git a/arch/x86/kernel/cpu/resctrl/rdtgroup.c b/arch/x86/kernel/cpu/r= esctrl/rdtgroup.c index 51b869149e76..6a301233b9ef 100644 --- a/arch/x86/kernel/cpu/resctrl/rdtgroup.c +++ b/arch/x86/kernel/cpu/resctrl/rdtgroup.c @@ -3514,6 +3514,133 @@ static int rdtgroup_rmdir(struct kernfs_node *kn) return ret; } =20 +/** + * mongrp_reparent() - replace parent CTRL_MON group of a MON group + * @rdtgrp: the MON group whose parent should be replaced + * @new_prdtgrp: replacement parent CTRL_MON group for @rdtgrp + * @cpus: cpumask provided by the caller for use during this call + * + * Replaces the parent CTRL_MON group for a MON group, resulting in all me= mber + * tasks' CLOSID immediately changing to that of the new parent group. + * Monitoring data for the group is unaffected by this operation. + */ +static void mongrp_reparent(struct rdtgroup *rdtgrp, + struct rdtgroup *new_prdtgrp, + cpumask_var_t cpus) +{ + struct rdtgroup *prdtgrp =3D rdtgrp->mon.parent; + + WARN_ON(rdtgrp->type !=3D RDTMON_GROUP); + WARN_ON(new_prdtgrp->type !=3D RDTCTRL_GROUP); + + /* Nothing to do when simply renaming a MON group. */ + if (prdtgrp =3D=3D new_prdtgrp) + return; + + WARN_ON(list_empty(&prdtgrp->mon.crdtgrp_list)); + list_move_tail(&rdtgrp->mon.crdtgrp_list, + &new_prdtgrp->mon.crdtgrp_list); + + rdtgrp->mon.parent =3D new_prdtgrp; + rdtgrp->closid =3D new_prdtgrp->closid; + + /* Propagate updated closid to all tasks in this group. */ + rdt_move_group_tasks(rdtgrp, rdtgrp, cpus); + + update_closid_rmid(cpus, NULL); +} + +static int rdtgroup_rename(struct kernfs_node *kn, + struct kernfs_node *new_parent, const char *new_name) +{ + struct rdtgroup *new_prdtgrp; + struct rdtgroup *rdtgrp; + cpumask_var_t tmpmask; + int ret; + + rdtgrp =3D kernfs_to_rdtgroup(kn); + new_prdtgrp =3D kernfs_to_rdtgroup(new_parent); + if (!rdtgrp || !new_prdtgrp) + return -ENOENT; + + /* Release both kernfs active_refs before obtaining rdtgroup mutex. */ + rdtgroup_kn_get(rdtgrp, kn); + rdtgroup_kn_get(new_prdtgrp, new_parent); + + mutex_lock(&rdtgroup_mutex); + + rdt_last_cmd_clear(); + + /* + * Don't allow kernfs_to_rdtgroup() to return a parent rdtgroup if + * either kernfs_node is a file. + */ + if (kernfs_type(kn) !=3D KERNFS_DIR || + kernfs_type(new_parent) !=3D KERNFS_DIR) { + rdt_last_cmd_puts("Source and destination must be directories"); + ret =3D -EPERM; + goto out; + } + + if ((rdtgrp->flags & RDT_DELETED) || (new_prdtgrp->flags & RDT_DELETED)) { + ret =3D -ENOENT; + goto out; + } + + if (rdtgrp->type !=3D RDTMON_GROUP || !kn->parent || + !is_mon_groups(kn->parent, kn->name)) { + rdt_last_cmd_puts("Source must be a MON group\n"); + ret =3D -EPERM; + goto out; + } + + if (!is_mon_groups(new_parent, new_name)) { + rdt_last_cmd_puts("Destination must be a mon_groups subdirectory\n"); + ret =3D -EPERM; + goto out; + } + + /* + * If the MON group is monitoring CPUs, the CPUs must be assigned to the + * current parent CTRL_MON group and therefore cannot be assigned to + * the new parent, making the move illegal. + */ + if (!cpumask_empty(&rdtgrp->cpu_mask) && + rdtgrp->mon.parent !=3D new_prdtgrp) { + rdt_last_cmd_puts("Cannot move a MON group that monitors CPUs\n"); + ret =3D -EPERM; + goto out; + } + + /* + * Allocate the cpumask for use in mongrp_reparent() to avoid the + * possibility of failing to allocate it after kernfs_rename() has + * succeeded. + */ + if (!zalloc_cpumask_var(&tmpmask, GFP_KERNEL)) { + ret =3D -ENOMEM; + goto out; + } + + /* + * Perform all input validation and allocations needed to ensure + * mongrp_reparent() will succeed before calling kernfs_rename(), + * otherwise it would be necessary to revert this call if + * mongrp_reparent() failed. + */ + ret =3D kernfs_rename(kn, new_parent, new_name); + if (!ret) + mongrp_reparent(rdtgrp, new_prdtgrp, tmpmask); + + free_cpumask_var(tmpmask); + +out: + mutex_unlock(&rdtgroup_mutex); + rdtgroup_kn_put(rdtgrp, kn); + rdtgroup_kn_put(new_prdtgrp, new_parent); + return ret; +} + static int rdtgroup_show_options(struct seq_file *seq, struct kernfs_root = *kf) { if (resctrl_arch_get_cdp_enabled(RDT_RESOURCE_L3)) @@ -3531,6 +3658,7 @@ static int rdtgroup_show_options(struct seq_file *seq= , struct kernfs_root *kf) static struct kernfs_syscall_ops rdtgroup_kf_syscall_ops =3D { .mkdir =3D rdtgroup_mkdir, .rmdir =3D rdtgroup_rmdir, + .rename =3D rdtgroup_rename, .show_options =3D rdtgroup_show_options, }; =20 --=20 2.40.0.634.g4ca3ef3211-goog From nobody Sun Sep 14 07:53:02 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 791B0C77B73 for ; Wed, 19 Apr 2023 12:51:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233293AbjDSMvI (ORCPT ); Wed, 19 Apr 2023 08:51:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34506 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233181AbjDSMu7 (ORCPT ); Wed, 19 Apr 2023 08:50:59 -0400 Received: from mail-yw1-x114a.google.com (mail-yw1-x114a.google.com [IPv6:2607:f8b0:4864:20::114a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 83CA1B76B for ; Wed, 19 Apr 2023 05:50:47 -0700 (PDT) Received: by mail-yw1-x114a.google.com with SMTP id 00721157ae682-54f8b46f399so196280237b3.10 for ; Wed, 19 Apr 2023 05:50:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1681908646; x=1684500646; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=qxACaIFQGSNpRzNrd0szUQtmVWzyEP8n7N2A/6ory1w=; b=f8BJoFC7tHMQtMMZnfHw8I7h0dvExKxzjkvC1CMzEqKyAmbkh0GKgpFLaAWbEVpRjA KwfORX59VwoQc9As8pK/qPW6dAwLa0GNz5YGckzd2SxjJAB+WusEdU5iE9hLk6K40ddH ewr//TybzLFRVfXLg43mMTSXfIThG52oMVeKsfCAnfnBfKGzuikbe8QyrRSsxmhsBMhm Tbuqw/GX+fnSmwH6+sk1ehjQgOV2M7TStxE5Cu6h1H1Xnn+tKVwb/Ft/TycpMOP5gvgD Lee6Gl6yu5sPMpAHI7kNDmwgdQYDFy1pHTXuYqKuSGsxnu1+HBkxrkyzN37oY0dSXHWK 9vOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681908646; x=1684500646; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=qxACaIFQGSNpRzNrd0szUQtmVWzyEP8n7N2A/6ory1w=; b=DVK7ovFmHkKEFkZpN6u/ZbehZQL9OlVhwSP9a7hCgvzk954WrkJaNRfENPS92V7NGn tAJr3LgM2QC9tMooxtWd2uLcCu4zi8TQxu03yjGdAX+ABbc9KD8ZjdGS2RBqY87jIpJV 6HcntZIY3OFvYqT9Gn4PqMMqd6He36kBtwj1hXWu71TSvm0USQyNTWceD2hsWlXPxjUW pKceL2DUzgZ3KZf/c8wnSsyJK2OTgqkkTXpPAT+aF22b1VkqV/c+2xH586Yx/zWnpECt Ea+bPb6kLZnXZpnZacytwxKr455LpRpo8jSpdDWYGba55wxctUw60rGfgZRLo30BXfla s/ZQ== X-Gm-Message-State: AAQBX9dn0WW74qmxiiQu/uztr3lt3JA5WL07KdC62SkclGi4t2izS4Qp syhTkOR/CHYf1/jdGG1gnCxhOfSstKy9ngdGJA== X-Google-Smtp-Source: AKy350bCA68l2s/hyXv+80wcZIx+NsacgD3N8B5t1pOuM2ss3p58l/o9YBIxQPYG61AMyYvrkXbrRuBqKnLcwwOxgg== X-Received: from peternewman0.zrh.corp.google.com ([2a00:79e0:9d:6:b36e:a25e:826d:b66a]) (user=peternewman job=sendgmr) by 2002:a25:d256:0:b0:b95:6caa:a2cb with SMTP id j83-20020a25d256000000b00b956caaa2cbmr3621411ybg.10.1681908646729; Wed, 19 Apr 2023 05:50:46 -0700 (PDT) Date: Wed, 19 Apr 2023 14:50:15 +0200 In-Reply-To: <20230419125015.693566-1-peternewman@google.com> Mime-Version: 1.0 References: <20230419125015.693566-1-peternewman@google.com> X-Mailer: git-send-email 2.40.0.634.g4ca3ef3211-goog Message-ID: <20230419125015.693566-4-peternewman@google.com> Subject: [PATCH v6 3/3] Documentation/x86: Documentation for MON group move feature From: Peter Newman To: fenghua.yu@intel.com, reinette.chatre@intel.com Cc: Babu.Moger@amd.com, bp@alien8.de, dave.hansen@linux.intel.com, eranian@google.com, gupasani@google.com, hpa@zytor.com, james.morse@arm.com, linux-kernel@vger.kernel.org, mingo@redhat.com, skodak@google.com, tglx@linutronix.de, tony.luck@intel.com, x86@kernel.org, Peter Newman Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Describe new support for moving MON groups to a new parent CTRL_MON group and its restrictions. Signed-off-by: Peter Newman Reviewed-by: Reinette Chatre Tested-by: Babu Moger --- Documentation/x86/resctrl.rst | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/Documentation/x86/resctrl.rst b/Documentation/x86/resctrl.rst index 387ccbcb558f..cb05d90111b4 100644 --- a/Documentation/x86/resctrl.rst +++ b/Documentation/x86/resctrl.rst @@ -287,6 +287,13 @@ Removing a directory will move all tasks and cpus owne= d by the group it represents to the parent. Removing one of the created CTRL_MON groups will automatically remove all MON groups below it. =20 +Moving MON group directories to a new parent CTRL_MON group is supported +for the purpose of changing the resource allocations of a MON group +without impacting its monitoring data or assigned tasks. This operation +is not allowed for MON groups which monitor CPUs. No other move +operation is currently allowed other than simply renaming a CTRL_MON or +MON group. + All groups contain the following files: =20 "tasks": --=20 2.40.0.634.g4ca3ef3211-goog