From: Tejun Heo <tj@kernel.org>
To: Brian Welty <brian.welty@intel.com>
Cc: "Leon Romanovsky" <leon@kernel.org>,
"David Airlie" <airlied@linux.ie>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Felix Kuehling" <Felix.Kuehling@amd.com>,
dri-devel@lists.freedesktop.org, "Kenny Ho" <Kenny.Ho@amd.com>,
cgroups@vger.kernel.org,
"Christian König" <christian.koenig@amd.com>
Subject: Re: [RFC PATCH] cgroup: Document interface files and rationale for DRM controller
Date: Mon, 4 Nov 2019 16:15:05 -0800 [thread overview]
Message-ID: <20191105001505.GR3622521@devbig004.ftw2.facebook.com> (raw)
In-Reply-To: <20191104220847.23283-1-brian.welty@intel.com>
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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2019-11-05 0:15 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-04 22:08 [RFC PATCH] cgroup: Document interface files and rationale for DRM controller Brian Welty
2019-11-05 0:15 ` Tejun Heo [this message]
2019-11-06 0:08 ` Brian Welty
2019-11-07 15:29 ` Tejun Heo
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=20191105001505.GR3622521@devbig004.ftw2.facebook.com \
--to=tj@kernel.org \
--cc=Felix.Kuehling@amd.com \
--cc=Kenny.Ho@amd.com \
--cc=airlied@linux.ie \
--cc=brian.welty@intel.com \
--cc=cgroups@vger.kernel.org \
--cc=christian.koenig@amd.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=gregkh@linuxfoundation.org \
--cc=leon@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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox