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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

-- 
tejun



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]     [Monitors]

  Powered by Linux