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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
