[RFC PATCH] cgroup: Document interface files and rationale for DRM controller

[Brian Welty]

On 11/4/2019 4:15 PM, Tejun Heo wrote:
> On Mon, Nov 04, 2019 at 05:08:47PM -0500, Brian Welty wrote:
>> +  gpuset.units
>> +  gpuset.units.effective
>> +  gpuset.units.partition
>> +
>> +  gpuset.mems
>> +  gpuset.mems.effective
>> +  gpuset.mems.partition
>> +
>> +  sched.max
>> +  sched.stats
>> +  sched.weight
>> +  sched.weight.nice
>> +
>> +  memory.current
>> +  memory.events
>> +  memory.high
>> +  memory.low
>> +  memory.max
>> +  memory.min
>> +  memory.stat
>> +  memory.swap.current
>> +  memory.swap.max
> 
> I don't understand why it needs to replicate essentially *all* the
> interfaces that system resources are implementing from the get-go.
> Some of the above have intersecting functionalities and exist more for
> historical reasons and I fail to see how distinctions like min vs. low
> and high vs. max would make sense for gpus.  Also, why would it have a
> separate swap limit of its own?
> 
> Please start with something small and intuitive.  I'm gonna nack
> anything which sprawls out like this.  Most likely, there's still a
> ton you guys need to work through to reach the resource model which is
> actually useful and trying to define a comprehensive interface upfront
> like this is gonna look really silly and will become an ugly drag by
> the time the problem space is actually understood.
> 
> It doesn't seem like this is coming through but can you please start
> with a simple weight knob?
> 
> Thanks.
> 

Thanks Tejun for the feedback.
I was more interested in hearing your thoughts on whether you like
the approach to have a set of controls that are consistent with 
some subset of the existing CPU/MEM ones.  Any feedback on this?
Didn't really mean to suggest that all of these would be included
from the start.

Would you agree that this reduced set is a reasonable starting point?
+  sched.weight
+  memory.current
+  memory.max

Thoughts on whether this should be very GPU-specific cgroups controller
or should be more forward thinking to be useful for other 'accelerator'
type devices as well?

Thanks,
-Brian