Re: [Patch v3 0/2] cgroup: KVM: New Encryption IDs cgroup controller

2021-01-06 Thread Vipin Sharma
On Tue, Jan 05, 2021 at 10:36:40AM -0500, Tejun Heo wrote: > Happy new year! > > On Wed, Dec 16, 2020 at 12:02:37PM -0800, Vipin Sharma wrote: > > I like the idea of having a separate controller to keep the code simple and > > easier for maintenance. > > Yeah, the more I think about it, keeping i

Re: [Patch v3 0/2] cgroup: KVM: New Encryption IDs cgroup controller

2021-01-05 Thread Tejun Heo
Happy new year! On Wed, Dec 16, 2020 at 12:02:37PM -0800, Vipin Sharma wrote: > I like the idea of having a separate controller to keep the code simple and > easier for maintenance. Yeah, the more I think about it, keeping it separate seems like the right thing to do. What bothers me primarily is

Re: [Patch v3 0/2] cgroup: KVM: New Encryption IDs cgroup controller

2020-12-16 Thread Vipin Sharma
On Wed, Dec 9, 2020 at 12:59 PM Tejun Heo wrote: > * I don't have an overall objection. In terms of behavior, the only thing > which stood out was input rejection depending on the current usage. The > preferred way of handling that is rejecting future allocations rather than > failing config

Re: [Patch v3 0/2] cgroup: KVM: New Encryption IDs cgroup controller

2020-12-16 Thread Tejun Heo
Hello, On Thu, Dec 10, 2020 at 03:44:35PM -0800, David Rientjes wrote: > Concern with a single misc controller would be that any subsystem that > wants to use it has to exactly fit this support: current, max, stat, > nothing more. The moment a controller needs some additional support, and > it

Re: [Patch v3 0/2] cgroup: KVM: New Encryption IDs cgroup controller

2020-12-10 Thread David Rientjes
On Thu, 10 Dec 2020, Christian Borntraeger wrote: > > * However, the boilerplate to usefulness ratio doesn't look too good and I > > wonder whether what we should do is adding a generic "misc" controller > > which can host this sort of static hierarchical counting. I'll think more > > on it.

Re: [Patch v3 0/2] cgroup: KVM: New Encryption IDs cgroup controller

2020-12-10 Thread Christian Borntraeger
On 09.12.20 21:58, Tejun Heo wrote: > Hello, > > Rough take after skimming: > > * I don't have an overall objection. In terms of behavior, the only thing > which stood out was input rejection depending on the current usage. The > preferred way of handling that is rejecting future allocations

Re: [Patch v3 0/2] cgroup: KVM: New Encryption IDs cgroup controller

2020-12-09 Thread Tejun Heo
Hello, Rough take after skimming: * I don't have an overall objection. In terms of behavior, the only thing which stood out was input rejection depending on the current usage. The preferred way of handling that is rejecting future allocations rather than failing configuration as that makes