All of lore.kernel.org
 help / color / mirror / Atom feed
From: Reinette Chatre <reinette.chatre@intel.com>
To: Peter Newman <peternewman@google.com>
Cc: Tony Luck <tony.luck@intel.com>,
	"Yu, Fenghua" <fenghua.yu@intel.com>,
	"Eranian, Stephane" <eranian@google.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	"James Morse" <james.morse@arm.com>,
	Babu Moger <Babu.Moger@amd.com>,
	"Gaurang Upasani" <gupasani@google.com>
Subject: Re: [RFD] resctrl: reassigning a running container's CTRL_MON group
Date: Wed, 19 Oct 2022 16:54:30 -0700	[thread overview]
Message-ID: <b931062a-1a70-2331-03cc-6bfa69a51bee@intel.com> (raw)
In-Reply-To: <CALPaoCg4zrODVoXF2y2b+LRYq_+jnV8yv5qB+T_3Z264cV82GQ@mail.gmail.com>

Hi Peter,

On 10/19/2022 2:08 AM, Peter Newman wrote:
> Hi Reinette,
> 
> On Wed, Oct 12, 2022 at 7:23 PM Reinette Chatre
> <reinette.chatre@intel.com> wrote:
>> What if resctrl adds support to rdtgroup_kf_syscall_ops for
>> the .rename callback?
>>
>> It seems like doing so could enable users to do something like:
>> mv /sys/fs/resctrl/groupA/mon_groups/containerA /sys/fs/resctrl/groupB/mon_groups/
>>
>> Such a user request would trigger the "containerA" monitor group
>> to be moved to another control group. All tasks within it could be moved to
>> the new control group (their CLOSIDs are changed) while their RMIDs
>> remain intact.
> 
> I think this will be the best approach for us, since we need separate
> counters for every job. Unless you were planning to implement this very
> soon, I will prototype it for the container manager team to try out and
> submit patches for review if it works for them.

I do not have plans for work in this area.

It is still not clear to me how palatable this will be on Arm systems. 
This solution also involves changing the CLOSID/PARTID like your original
proposal and James highlighted that it would "mess up the bandwidth counters"
because of the way PARTID.PMG is used for monitoring. Perhaps even a new
PMG would need to be assigned during such a monitor group move. One requirement
for this RFD was to keep usage counts intact and from what I understand
this will not be possible on Arm systems.  There could be software mechanisms
to help reduce the noise during the transition. For example, some new limbo
mechanism that avoids re-assigning the old PARTID.PMG, while perhaps still
using the old PARTID.PMG to read usage counts for a while? Or would the
guidance just be that the counters will have some noise after the move?

Reinette

  parent reply	other threads:[~2022-10-19 23:55 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-07 10:39 [RFD] resctrl: reassigning a running container's CTRL_MON group Peter Newman
2022-10-07 15:36 ` Reinette Chatre
2022-10-07 15:44   ` Yu, Fenghua
2022-10-07 17:28     ` Tony Luck
2022-10-10 23:35       ` Reinette Chatre
2022-10-12 11:21         ` Peter Newman
2022-10-12 16:55           ` James Morse
2022-10-17 10:15             ` Peter Newman
2022-10-19 13:57               ` James Morse
2022-10-20 10:39                 ` Peter Newman
2022-10-21 12:42                   ` Peter Newman
2022-10-25 15:55                     ` James Morse
2022-10-26  8:52                       ` Peter Newman
2022-10-26 21:12                         ` Reinette Chatre
2022-10-27  7:56                           ` Peter Newman
2022-10-27 17:35                             ` Reinette Chatre
2022-11-01 15:23                               ` Peter Newman
2022-11-01 15:53                                 ` Peter Newman
2022-11-01 16:48                                   ` Reinette Chatre
2022-10-25 15:56                   ` James Morse
2022-10-21 20:09                 ` Reinette Chatre
2022-10-21 20:22                   ` Luck, Tony
2022-10-21 21:34                     ` Reinette Chatre
2022-11-03 17:06                   ` James Morse
2022-11-08 21:28                     ` Reinette Chatre
2022-11-08 21:56                       ` Luck, Tony
2022-11-08 23:18                         ` Reinette Chatre
2022-11-09 17:58                           ` James Morse
2022-11-09  9:50                       ` Peter Newman
2022-11-09 19:11                         ` Reinette Chatre
2022-11-11 18:38                           ` James Morse
2022-11-14 18:02                             ` Reinette Chatre
2022-11-16 13:20                             ` Peter Newman
2022-11-09 17:59                       ` James Morse
2022-11-09 19:12                         ` Reinette Chatre
2022-11-11 18:36                           ` James Morse
2022-10-12 16:57           ` Yu, Fenghua
2022-10-12 17:23           ` Reinette Chatre
2022-10-14 12:56             ` James Morse
2022-10-19  9:08             ` Peter Newman
2022-10-19 13:20               ` James Morse
2022-10-19 23:54               ` Reinette Chatre [this message]
2022-10-20  8:48                 ` Peter Newman
2022-10-20 19:08                   ` Reinette Chatre
2022-10-21 10:09                     ` Peter Newman
2022-10-25 15:56                       ` James Morse
2022-10-25 15:55                     ` James Morse
2022-10-26  9:36                       ` Peter Newman
2022-11-03 17:06                         ` James Morse
2022-11-08 21:25                           ` Reinette Chatre
2022-10-07 17:57 ` Moger, Babu
2022-10-11 15:00   ` Stephane Eranian
2022-10-11 14:59 ` Stephane Eranian

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b931062a-1a70-2331-03cc-6bfa69a51bee@intel.com \
    --to=reinette.chatre@intel.com \
    --cc=Babu.Moger@amd.com \
    --cc=eranian@google.com \
    --cc=fenghua.yu@intel.com \
    --cc=gupasani@google.com \
    --cc=james.morse@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peternewman@google.com \
    --cc=tglx@linutronix.de \
    --cc=tony.luck@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.