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: Thu, 7 Nov 2019 07:29:14 -0800 [thread overview]
Message-ID: <20191107152914.GU3622521@devbig004.ftw2.facebook.com> (raw)
In-Reply-To: <d565fc2c-0bd0-a85a-c7ce-12ee5393154d@intel.com>
Hello,
On Tue, Nov 05, 2019 at 04:08:22PM -0800, Brian Welty wrote:
> 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.
I don't see why they should be synchronized. If it ends up being
about the same anyway, there's no reason to not sync them but that
doesn't seem very likely to me and trying to sync sounds like adding
an unnecessary constraint. One side of the ballot is possibly missing
on aesthetics a bit while the other side is constraining interface
design even before understanding the design space, so...
> 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?
My preference is starting small and focused. GPU by itself is already
a big enough problem and the progress upto this point evidently
indicates even that alone is poorly mapped out. Please start with the
smallest and most common (tied to usage, not hardware) interface
that's viable.
Thanks.
--
tejun
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
prev parent reply other threads:[~2019-11-07 15:29 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
2019-11-06 0:08 ` Brian Welty
2019-11-07 15:29 ` Tejun Heo [this message]
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=20191107152914.GU3622521@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