Intel-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Tejun Heo <tj@kernel.org>
To: Matt Roper <matthew.d.roper@intel.com>
Cc: cgroups@vger.kernel.org, intel-gfx@lists.freedesktop.org,
	dri-devel@lists.freedesktop.org
Subject: Re: [IGT PATCH RFC] tools: Introduce intel_cgroup tool
Date: Wed, 7 Feb 2018 13:50:03 -0800	[thread overview]
Message-ID: <20180207215003.GH695913@devbig577.frc2.facebook.com> (raw)
In-Reply-To: <20180201231437.GJ31510@mdroper-desk.amr.corp.intel.com>

Hello, Matt, Chris.

On Thu, Feb 01, 2018 at 03:14:38PM -0800, Matt Roper wrote:
> > Hmm. Could we not avoid drm_ioctl + well known param names and use a
> > more generic tool to set cgroup attributes? Just feels wrong that a
> > such a generic interface boils down to a driver specific ioctl.

So, everything which shows up in the cgroup hierarchy should satisfy
the following two conditions.

* The control mechanism should adhere to one of the resource
  distribution models defined in Documentation/cgroup-v2.txt.  This is
  to ensure consistency across different resources which in turn
  allows things like delegation.

* This one is a bit vague and I probably should find a better way to
  describe it but each controller should encapsulate a generic core
  resource.  Here, I don't think it makes sense to have intel gfx
  controller when there are a lot of commmonalities in the graphics
  hardware across different vendors.  It should be better abstracted.

It's true that it's difficult to figure out the right generic design
without actually trying, and I think that's why it'd be better to
start scoped in the scope of the specific driver.  The smaller scope
would allow for less strict expectations, more latitude, and easier
experimentations.

> I think the nicest interface for setting cgroup attributes would be to
> find a way to add our own kernfs entries to the cgroup filesystem, the
> same way real cgroup controllers do.  Then we could do something like
> "echo 123 > /cgroup2/apps/highprio/i915.card0.priority" and not need to
> call any ioctl's at all.  Without creating an actual cgroup controller,
> I think this might be challenging, but I'm investigating it on the side
> right now to see if it's a viable option.

So, I strongly believe that it isn't the right approach to add i915
prefixed interface files to cgroup interface.

Thanks.

-- 
tejun
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2018-02-07 21:50 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-01 19:53 [PATCH RFC v2 0/7] DRM management via cgroups Matt Roper
2018-02-01 19:53 ` [PATCH RFC v2 1/7] cgroup: Allow drivers to store data associated with a cgroup Matt Roper
     [not found]   ` <20180201195315.4956-2-matthew.d.roper-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2018-02-07 22:11     ` Tejun Heo
2018-02-01 19:53 ` [PATCH RFC v2 2/7] kernfs: Export kernfs_get_inode Matt Roper
     [not found]   ` <20180201195315.4956-3-matthew.d.roper-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2018-02-01 20:04     ` [Intel-gfx] " Chris Wilson
2018-02-01 19:53 ` [PATCH RFC v2 3/7] cgroup: Add interface to allow drivers to lookup process cgroup membership Matt Roper
2018-02-01 20:49   ` [Intel-gfx] " Chris Wilson
2018-02-01 21:25     ` Matt Roper
2018-02-07 22:42   ` Tejun Heo
2018-02-01 19:53 ` [PATCH RFC v2 4/7] drm: Add helper to obtain cgroup of drm_file's owning process Matt Roper
     [not found]   ` <20180201195315.4956-5-matthew.d.roper-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2018-02-01 20:10     ` [Intel-gfx] " Chris Wilson
2018-02-01 19:53 ` [PATCH RFC v2 5/7] drm/i915: cgroup integration Matt Roper
     [not found]   ` <20180201195315.4956-6-matthew.d.roper-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2018-02-01 20:11     ` Chris Wilson
2018-02-01 20:12     ` Chris Wilson
2018-02-01 20:15   ` Chris Wilson
     [not found] ` <20180201195315.4956-1-matthew.d.roper-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2018-02-01 19:53   ` [PATCH RFC v2 6/7] drm/i915: Introduce 'priority offset' for GPU contexts Matt Roper
     [not found]     ` <20180201195315.4956-7-matthew.d.roper-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2018-02-01 20:22       ` Chris Wilson
2018-02-01 19:53   ` [PATCH RFC v2 7/7] drm/i915: Add context priority & priority offset to debugfs Matt Roper
     [not found]     ` <20180201195315.4956-8-matthew.d.roper-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2018-02-01 20:24       ` Chris Wilson
2018-02-01 19:56 ` [IGT PATCH RFC] tools: Introduce intel_cgroup tool Matt Roper
2018-02-01 20:27   ` [Intel-gfx] " Chris Wilson
     [not found]     ` <151751685381.28099.5351495854502256843-M6iVdVfohj6unts5RBS2dVaTQe2KTcn/@public.gmane.org>
2018-02-01 23:14       ` Matt Roper
2018-02-07 21:50         ` Tejun Heo [this message]
2018-02-07 21:54         ` Tejun Heo
2018-02-01 20:14 ` ✓ Fi.CI.BAT: success for DRM management via cgroups (rev2) Patchwork
2018-02-01 20:15 ` ✗ Fi.CI.BAT: failure for tools: Introduce intel_cgroup tool Patchwork
2018-02-01 23:52 ` ✗ Fi.CI.IGT: failure for DRM management via cgroups (rev2) Patchwork

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=20180207215003.GH695913@devbig577.frc2.facebook.com \
    --to=tj@kernel.org \
    --cc=cgroups@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=matthew.d.roper@intel.com \
    /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