From nobody Sat Apr 11 17:23:09 2026 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 79D8FC6FD1D for ; Thu, 30 Mar 2023 13:56:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232225AbjC3N4V (ORCPT ); Thu, 30 Mar 2023 09:56:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43570 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232090AbjC3N4Q (ORCPT ); Thu, 30 Mar 2023 09:56:16 -0400 Received: from mail-yb1-xb4a.google.com (mail-yb1-xb4a.google.com [IPv6:2607:f8b0:4864:20::b4a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E3EA67ED3 for ; Thu, 30 Mar 2023 06:56:14 -0700 (PDT) Received: by mail-yb1-xb4a.google.com with SMTP id p12-20020a25420c000000b00b6eb3c67574so18710889yba.11 for ; Thu, 30 Mar 2023 06:56:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; t=1680184574; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=Db8tOgMamx6SeqgPHUVcNRbWY9TzQjouDMjbLfKO9Bs=; b=smbJl9qFP0l+li/hTveSDyoWOwzoPsoLgc8Y/ZUlzb4z79RlsRniVMcWs8fQnlPjSe aZIByw2LkyVG+iujSfkEbBIxijps0U3JAGOLzKQD9VF1QS6DCfGVK5PsbLIIh3MtvbGo T3VY05+yvWDx1cCieWInbheUEtsfNdp1dtZDEiXe5SSdR+eR8joFUtII4AWaimvlXvG/ sfl8ELaGwsoupYMFHqtKEz38EFqsNC1R1YPxJO4rYlNrGruq5MFrZBGFSN37GhwGY3YM EiffeAwYzCqWYR2AfbaJ5EMGJt94EYC2UWzEKmgiyjaM0LGsMIo42eXzY/vwAOpfHseR 5XvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680184574; 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=Db8tOgMamx6SeqgPHUVcNRbWY9TzQjouDMjbLfKO9Bs=; b=gU9E7ULLyDdmcirBkjTeTWqU4+iGJdrcdwnCLHw7oP7fkqL5krbwnGGb/oOrnYis3f Jx+p2aNKbLcrYy/La0AzK0NIOheOmkO346hXUuI2Y4z881rqzphx07V3Fh0AyBxhjrAE 57WpW+bRcoF7FfJByqZfijavVtvNdlwIjLysTBS68fZUD+nVuvUKF4I2A93ERrJRcmVj 7fOi7n+AJEPS4zYjCqlxwQsv4XX5Fm6IZsl31TFTyUNHoCO8o9biOxCEeXKTJjrBInLj P25jVRmkbTToM/VOVB3/ZdQBMe76u6h8/yzX8R2wXJ0OzGa44SRQyXYEltfxkOZ4qaeY 70oQ== X-Gm-Message-State: AAQBX9eiwQxG2JrDdXoFDNb9fot4l2s91+f2wduds3/LdH6P1KlFiI5n 07YzujE2xLt8AK7bNISKFfeqk1Ud01trBIPKXg== X-Google-Smtp-Source: AKy350Ynv1vxx40E2oldcA4Py+mSsLVEYWd4jHB1q+kGBD7GhiGINNV6dTkxr5askTOXvA2Ej4MyLxfovDjmFHGkMw== X-Received: from peternewman-vh.c.googlers.com ([fda3:e722:ac3:cc00:28:9cb1:c0a8:30cc]) (user=peternewman job=sendgmr) by 2002:a25:d9d6:0:b0:b80:e387:f6af with SMTP id q205-20020a25d9d6000000b00b80e387f6afmr50312ybg.2.1680184574244; Thu, 30 Mar 2023 06:56:14 -0700 (PDT) Date: Thu, 30 Mar 2023 15:55:56 +0200 In-Reply-To: <20230330135558.1019658-1-peternewman@google.com> Mime-Version: 1.0 References: <20230330135558.1019658-1-peternewman@google.com> X-Mailer: git-send-email 2.40.0.348.gf938b09366-goog Message-ID: <20230330135558.1019658-2-peternewman@google.com> Subject: [PATCH v5 1/3] x86/resctrl: Factor rdtgroup lock for multi-file ops From: Peter Newman To: reinette.chatre@intel.com, fenghua.yu@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 --- 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.348.gf938b09366-goog From nobody Sat Apr 11 17:23:09 2026 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 16038C6FD1D for ; Thu, 30 Mar 2023 13:56:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232227AbjC3N4X (ORCPT ); Thu, 30 Mar 2023 09:56:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43646 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232200AbjC3N4S (ORCPT ); Thu, 30 Mar 2023 09:56:18 -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 F2F51A25D for ; Thu, 30 Mar 2023 06:56:16 -0700 (PDT) Received: by mail-yb1-xb49.google.com with SMTP id 3-20020a251103000000b00b732e362449so18678539ybr.0 for ; Thu, 30 Mar 2023 06:56:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; t=1680184576; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=zUSjvVavoBhnwCV+A2EoFMdaaeZRtxo2g0qg4wUbJ74=; b=nFdvgINnXhDVlxrpogSpIYRXtjdRAXbnf98m/kRuK0EodxG5mqWMFnMpFcSH25JVGl Z26KpRi3NFGwWmA9HQDbA1ACoWItP92uCourv1Ebd7O6dnEL/y+kfdvI0W4rut6hpLEM vEPkUHtWrMb8nvj/yLpco1djR0W50o/oG8TGgORPshYudSPJT16BkvwHov5Qn0Xgeygj Qq8kAFtLYMHx/uK+Y0Md97BmZGw8keSkM59ndMeMJRIDTE624FRo+xvc2NlSusnp11OJ og214TR3Ix4mQocZSps+n19URYkCaiIeO5+MlpRGvsY7L8jiPnA0t5SXV0JFnHNo9L1S 70pg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680184576; 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=zUSjvVavoBhnwCV+A2EoFMdaaeZRtxo2g0qg4wUbJ74=; b=noEyJGo9bwj31tDqMLIZvHDS2yGa0hh9uRr7vvQpbZls9mw1Zqmb+foLEXOYqqaZ6A Pc70Ys4iw9JDZqbV1khRy768CE39Bl8NPQbzmGxUaAaPJHJJHEPZyLEEyKW95tL4wbK1 LE39S7GW0jCEqTOgPL0i2Hc6t7WGn1qPKwUwW1ITl4bxtesfPHye85p5wcikyAKs/2ms hFW/bL8wHTm2MYo6GtnZPIQXwebyNkK4YcX0cDaHPJfRfTwYQ0QELvYkTgOKEvKLX77B CmXni6TFwskcnrwE65V70Bce+3gji38Ye1FNpBgE6fSs2+q4Zzf2UBtfqC/i7swr0V2O PiJQ== X-Gm-Message-State: AAQBX9eT6QV8SR6s4GlZBfw9kSNt4OkK7ItJXh4BLbtMVSLRFzrvAeTT 55NJJ6uS2c8Zw03dkAQ2msqhva5dCqLJVoiwYg== X-Google-Smtp-Source: AKy350YQdbfyUH2mC0K7sidQEdaNrXG8HVZfulOEZPxxvrnYrj/VLDun/M/IjSpLxwds/actPAEoWcV0DGhDvUpnLA== X-Received: from peternewman-vh.c.googlers.com ([fda3:e722:ac3:cc00:28:9cb1:c0a8:30cc]) (user=peternewman job=sendgmr) by 2002:a81:9993:0:b0:544:bbd2:74be with SMTP id q141-20020a819993000000b00544bbd274bemr3549820ywg.4.1680184576236; Thu, 30 Mar 2023 06:56:16 -0700 (PDT) Date: Thu, 30 Mar 2023 15:55:57 +0200 In-Reply-To: <20230330135558.1019658-1-peternewman@google.com> Mime-Version: 1.0 References: <20230330135558.1019658-1-peternewman@google.com> X-Mailer: git-send-email 2.40.0.348.gf938b09366-goog Message-ID: <20230330135558.1019658-3-peternewman@google.com> Subject: [PATCH v5 2/3] x86/resctrl: Implement rename op for mon groups From: Peter Newman To: reinette.chatre@intel.com, fenghua.yu@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. If a container manager is additionally tracking containers' bandwidth usage by placing tasks from each into their own monitoring group, it must first move the tasks to the default monitoring group of the new control group before it can move the tasks into their new monitoring groups. 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 --- 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..86de22d8e23a 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 group 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.348.gf938b09366-goog From nobody Sat Apr 11 17:23:09 2026 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 E46E9C761A6 for ; Thu, 30 Mar 2023 13:56:28 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232236AbjC3N41 (ORCPT ); Thu, 30 Mar 2023 09:56:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43736 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232220AbjC3N4U (ORCPT ); Thu, 30 Mar 2023 09:56:20 -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 4462C9773 for ; Thu, 30 Mar 2023 06:56:19 -0700 (PDT) Received: by mail-yw1-x114a.google.com with SMTP id 00721157ae682-5416d3a321eso189188817b3.12 for ; Thu, 30 Mar 2023 06:56:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; t=1680184578; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=FhHLbziee4a81RNVkwycWkVgS8ETVW18Svhu+GP0co8=; b=TyIuTP4E/yt61TucQWoc7ll1E7roUOPolzxGJTLTcqFDT2S/awduj2ZxA31PhqG1eF pViFXGegRdXk1ZTQ1OZiFE84LpP8jzsgn5zGDzv8AfrdWtz6bUP4a38bqGQjQBPJ7ZPH VkpbiejhTh9WxOtxYFgi2Qmq/M4rZEvietQrflSUdzWuJf++ttuV3FQxBs8pvHzOH7dS pIF9Zlu0Zj8zj2b8UjbcSAC+Qa2zita4jFlJyqqgUMuEAE0ugdalIvKQZ0IclWc6ztrh 2J5QMvqUqijxIcADyhc2S97LPFZtPxcQJxl2OXorPFY8J7zdu5g4232yUJThobhUeYdo WN2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680184578; 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=FhHLbziee4a81RNVkwycWkVgS8ETVW18Svhu+GP0co8=; b=h1Z4pKfq4Pcr5ZBR9ha4gqmHXfjk7LR1xQcEyMkVPR+WdbYDSuoOmqo+ijLdPh+JTU SKQQMw/rWMvV7OEJqzKqoJJKdJuzXZ0SBhGTBSucP/fzoM3VjSsV0s1mQv6wmIEqC648 HMJ/usjnXwIE73DUp9OaUMWI7jdVmNXsjp+o3DKhMRhstZcDIizfzx3YE2BTWLvuufxr oC1d5UZTAaD/Qs/kFzQbJuXQYA8tBF7N4ikMHjAdIle9tFwnxnrh58jtCZ7/b3PKbEWv K8/ubMZZzkGmJe8k74HQW+qd7noZpc/idg+M1+Jmf1VH3y46RKZCDfjjT3pfqj7WpmyD ChLg== X-Gm-Message-State: AAQBX9cK3Uv+jTA62R8EhRcJONcftwy7RTPa7KCHrwiFC5G6X5mNCWAC 0a6TffFLUbC46RWQDPIIVb3RVkoqLxv8HxtDvg== X-Google-Smtp-Source: AKy350a7NVHkW7b+E9eQZDgipTjPNuxq0WUrIjvNLjxZxx04gbqK2cynLJX6DcxdOG/OpZw/AYC6JOo5r4i58SQb1A== X-Received: from peternewman-vh.c.googlers.com ([fda3:e722:ac3:cc00:28:9cb1:c0a8:30cc]) (user=peternewman job=sendgmr) by 2002:a05:6902:1024:b0:b77:3f5a:8a53 with SMTP id x4-20020a056902102400b00b773f5a8a53mr11703160ybt.12.1680184578517; Thu, 30 Mar 2023 06:56:18 -0700 (PDT) Date: Thu, 30 Mar 2023 15:55:58 +0200 In-Reply-To: <20230330135558.1019658-1-peternewman@google.com> Mime-Version: 1.0 References: <20230330135558.1019658-1-peternewman@google.com> X-Mailer: git-send-email 2.40.0.348.gf938b09366-goog Message-ID: <20230330135558.1019658-4-peternewman@google.com> Subject: [PATCH v5 3/3] Documentation/x86: Documentation for MON group move feature From: Peter Newman To: reinette.chatre@intel.com, fenghua.yu@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 --- 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.348.gf938b09366-goog