From: Vipin Sharma <vipinsh@google.com> To: "Michal Koutný" <mkoutny@suse.com> Cc: tj@kernel.org, thomas.lendacky@amd.com, brijesh.singh@amd.com, jon.grimm@amd.com, eric.vantassell@amd.com, pbonzini@redhat.com, hannes@cmpxchg.org, frankja@linux.ibm.com, borntraeger@de.ibm.com, corbet@lwn.net, seanjc@google.com, vkuznets@redhat.com, wanpengli@tencent.com, jmattson@google.com, joro@8bytes.org, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, hpa@zytor.com, gingell@google.com, rientjes@google.com, dionnaglaze@google.com, kvm@vger.kernel.org, x86@kernel.org, cgroups@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFC 0/2] cgroup: New misc cgroup controller Date: Wed, 24 Feb 2021 16:06:44 -0800 [thread overview] Message-ID: <YDbqFE21UsEaFDuU@google.com> (raw) In-Reply-To: <YDVIYQhZ6ArGsr3n@blackbook> On Tue, Feb 23, 2021 at 07:24:33PM +0100, Michal Koutný wrote: > Hello. > > On Thu, Feb 18, 2021 at 11:55:47AM -0800, Vipin Sharma <vipinsh@google.com> wrote: > > This patch is creating a new misc cgroup controller for allocation and > > tracking of resources which are not abstract like other cgroup > > controllers. > Please don't refer to this as "allocation" anywhere, that has a specific > meaning (see Resource Distribution Models in > Documentation/admin-gruide/cgroup-v2.rst). Yeah, it should be "Limits". I will update the text. > > > This controller was initially proposed as encryption_id but after > > the feedbacks, it is now changed to misc cgroup. > > https://lore.kernel.org/lkml/20210108012846.4134815-2-vipinsh@google.com/ > Interesting generalization. I wonder what else could fit under this as > well. (It resembles pids controller on the cover.) > > > Please provide any feedback for this RFC or if it is good for > > merging then I can send a patch for merging. > A new controller is added exposed with v1 attributes. I'm not convinced > it is desirable to change the frozen v1 controllers' API? (And therefore > promote it as well.) This is a very trivial controller. I believe once it becomes public it can be helpful down the line to the v1 users, who cannot use v2 yet, for some simple resource accounting, like us, we have the need for ASIDs accounting in v1 until we move to v2. If the community has strong objection then I can remove v1 support. > > Beware, bikeshedding. The name is very non-descriptive, potentially > suggesting catch-all semantics. It'd deserve a further thought. My idea > would be limit(s) or counter controller. Limit and counter are kind of suggesting the underlying technique for accounting instead of a generic name to denote resource types managed by this controller. One can argue that if top level names are similar to Resource Destribution Model then may be it makes sense to combine resources with similar accounting technique under one controller. I am looking at misc as a controller which is for resources not having proper home in other controllers or not big enough to deserve their own controller. I agree with you coming up with a name which check all boxes of requirements won't be possible. We have discussed name sev cgroup, kvm cgroup, encryption_id cgroup before reaching to an agreement on misc cgroup. I am open to other names if they are better suited for this controller and makes more sense. Thanks Vipin
WARNING: multiple messages have this Message-ID (diff)
From: Vipin Sharma <vipinsh-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> To: "Michal Koutný" <mkoutny-IBi9RG/b67k@public.gmane.org> Cc: tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, thomas.lendacky-5C7GfCeVMHo@public.gmane.org, brijesh.singh-5C7GfCeVMHo@public.gmane.org, jon.grimm-5C7GfCeVMHo@public.gmane.org, eric.vantassell-5C7GfCeVMHo@public.gmane.org, pbonzini-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org, frankja-tEXmvtCZX7AybS5Ee8rs3A@public.gmane.org, borntraeger-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org, corbet-T1hC0tSOHrs@public.gmane.org, seanjc-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org, vkuznets-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, wanpengli-1Nz4purKYjRBDgjK7y7TUQ@public.gmane.org, jmattson-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org, joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org, tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org, mingo-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, bp-Gina5bIWoIWzQB+pC5nmwQ@public.gmane.org, hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org, gingell-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org, rientjes-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org, dionnaglaze-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org, kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org Subject: Re: [RFC 0/2] cgroup: New misc cgroup controller Date: Wed, 24 Feb 2021 16:06:44 -0800 [thread overview] Message-ID: <YDbqFE21UsEaFDuU@google.com> (raw) In-Reply-To: <YDVIYQhZ6ArGsr3n@blackbook> On Tue, Feb 23, 2021 at 07:24:33PM +0100, Michal Koutný wrote: > Hello. > > On Thu, Feb 18, 2021 at 11:55:47AM -0800, Vipin Sharma <vipinsh-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> wrote: > > This patch is creating a new misc cgroup controller for allocation and > > tracking of resources which are not abstract like other cgroup > > controllers. > Please don't refer to this as "allocation" anywhere, that has a specific > meaning (see Resource Distribution Models in > Documentation/admin-gruide/cgroup-v2.rst). Yeah, it should be "Limits". I will update the text. > > > This controller was initially proposed as encryption_id but after > > the feedbacks, it is now changed to misc cgroup. > > https://lore.kernel.org/lkml/20210108012846.4134815-2-vipinsh-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org/ > Interesting generalization. I wonder what else could fit under this as > well. (It resembles pids controller on the cover.) > > > Please provide any feedback for this RFC or if it is good for > > merging then I can send a patch for merging. > A new controller is added exposed with v1 attributes. I'm not convinced > it is desirable to change the frozen v1 controllers' API? (And therefore > promote it as well.) This is a very trivial controller. I believe once it becomes public it can be helpful down the line to the v1 users, who cannot use v2 yet, for some simple resource accounting, like us, we have the need for ASIDs accounting in v1 until we move to v2. If the community has strong objection then I can remove v1 support. > > Beware, bikeshedding. The name is very non-descriptive, potentially > suggesting catch-all semantics. It'd deserve a further thought. My idea > would be limit(s) or counter controller. Limit and counter are kind of suggesting the underlying technique for accounting instead of a generic name to denote resource types managed by this controller. One can argue that if top level names are similar to Resource Destribution Model then may be it makes sense to combine resources with similar accounting technique under one controller. I am looking at misc as a controller which is for resources not having proper home in other controllers or not big enough to deserve their own controller. I agree with you coming up with a name which check all boxes of requirements won't be possible. We have discussed name sev cgroup, kvm cgroup, encryption_id cgroup before reaching to an agreement on misc cgroup. I am open to other names if they are better suited for this controller and makes more sense. Thanks Vipin
next prev parent reply other threads:[~2021-02-25 0:07 UTC|newest] Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-02-18 19:55 [RFC 0/2] cgroup: New misc cgroup controller Vipin Sharma 2021-02-18 19:55 ` Vipin Sharma 2021-02-18 19:55 ` [RFC 1/2] cgroup: sev: Add " Vipin Sharma 2021-02-18 19:55 ` Vipin Sharma 2021-02-23 18:24 ` Michal Koutný 2021-02-25 4:57 ` Vipin Sharma 2021-02-25 9:52 ` Michal Koutný 2021-02-25 9:52 ` Michal Koutný 2021-02-25 19:28 ` Vipin Sharma 2021-02-26 14:23 ` Michal Koutný 2021-02-26 14:23 ` Michal Koutný 2021-02-18 19:55 ` [RFC 2/2] cgroup: sev: Miscellaneous cgroup documentation Vipin Sharma 2021-02-18 19:55 ` Vipin Sharma 2021-02-19 19:02 ` Randy Dunlap 2021-02-24 23:13 ` Vipin Sharma 2021-02-23 18:24 ` [RFC 0/2] cgroup: New misc cgroup controller Michal Koutný 2021-02-25 0:06 ` Vipin Sharma [this message] 2021-02-25 0:06 ` Vipin Sharma
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=YDbqFE21UsEaFDuU@google.com \ --to=vipinsh@google.com \ --cc=borntraeger@de.ibm.com \ --cc=bp@alien8.de \ --cc=brijesh.singh@amd.com \ --cc=cgroups@vger.kernel.org \ --cc=corbet@lwn.net \ --cc=dionnaglaze@google.com \ --cc=eric.vantassell@amd.com \ --cc=frankja@linux.ibm.com \ --cc=gingell@google.com \ --cc=hannes@cmpxchg.org \ --cc=hpa@zytor.com \ --cc=jmattson@google.com \ --cc=jon.grimm@amd.com \ --cc=joro@8bytes.org \ --cc=kvm@vger.kernel.org \ --cc=linux-doc@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=mingo@redhat.com \ --cc=mkoutny@suse.com \ --cc=pbonzini@redhat.com \ --cc=rientjes@google.com \ --cc=seanjc@google.com \ --cc=tglx@linutronix.de \ --cc=thomas.lendacky@amd.com \ --cc=tj@kernel.org \ --cc=vkuznets@redhat.com \ --cc=wanpengli@tencent.com \ --cc=x86@kernel.org \ /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: linkBe 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.