From: Daniel Vetter <daniel-/w4YWyX8dFk@public.gmane.org>
To: Kenny Ho <y2kenny-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: "Greathouse,
Joseph" <joseph.greathouse-5C7GfCeVMHo@public.gmane.org>,
"Kenny Ho" <Kenny.Ho-5C7GfCeVMHo@public.gmane.org>,
"Kuehling, Felix" <felix.kuehling-5C7GfCeVMHo@public.gmane.org>,
jsparks-WVYJKLFxKCc@public.gmane.org,
"amd-gfx list"
<amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>,
lkaplan-WVYJKLFxKCc@public.gmane.org,
"Alex Deucher" <alexander.deucher-5C7GfCeVMHo@public.gmane.org>,
dri-devel
<dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>,
"Daniel Vetter" <daniel-/w4YWyX8dFk@public.gmane.org>,
"Tejun Heo" <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
"Christian König" <christian.koenig-5C7GfCeVMHo@public.gmane.org>
Subject: Re: [PATCH RFC v4 01/16] drm: Add drm_minor_for_each
Date: Wed, 4 Sep 2019 10:54:34 +0200 [thread overview]
Message-ID: <20190904085434.GF2112@phenom.ffwll.local> (raw)
In-Reply-To: <CAOWid-eUVztW4hNVpznnJRcwHcjCirGL2aS75p4OY8XoGuJqUg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Tue, Sep 03, 2019 at 04:43:45PM -0400, Kenny Ho wrote:
> On Tue, Sep 3, 2019 at 4:12 PM Daniel Vetter <daniel@ffwll.ch> wrote:
> > On Tue, Sep 3, 2019 at 9:45 PM Kenny Ho <y2kenny@gmail.com> wrote:
> > > On Tue, Sep 3, 2019 at 3:57 AM Daniel Vetter <daniel@ffwll.ch> wrote:
> > > > Iterating over minors for cgroups sounds very, very wrong. Why do we care
> > > > whether a buffer was allocated through kms dumb vs render nodes?
> > > >
> > > > I'd expect all the cgroup stuff to only work on drm_device, if it does
> > > > care about devices.
> > > >
> > > > (I didn't look through the patch series to find out where exactly you're
> > > > using this, so maybe I'm off the rails here).
> > >
> > > I am exposing this to remove the need to keep track of a separate list
> > > of available drm_device in the system (to remove the registering and
> > > unregistering of drm_device to the cgroup subsystem and just use
> > > drm_minor as the single source of truth.) I am only filtering out the
> > > render nodes minor because they point to the same drm_device and is
> > > confusing.
> > >
> > > Perhaps I missed an obvious way to list the drm devices without
> > > iterating through the drm_minors? (I probably jumped to the minors
> > > because $major:$minor is the convention to address devices in cgroup.)
> >
> > Create your own if there's nothing, because you need to anyway:
> > - You need special locking anyway, we can't just block on the idr lock
> > for everything.
> > - This needs to refcount drm_device, no the minors.
> >
> > Iterating over stuff still feels kinda wrong still, because normally
> > the way we register/unregister userspace api (and cgroups isn't
> > anything else from a drm driver pov) is by adding more calls to
> > drm_dev_register/unregister. If you put a drm_cg_register/unregister
> > call in there we have a clean separation, and you can track all the
> > currently active devices however you want. Iterating over objects that
> > can be hotunplugged any time tends to get really complicated really
> > quickly.
>
> Um... I thought this is what I had previously. Did I misunderstood
> your feedback from v3? Doesn't drm_minor already include all these
> facilities so isn't creating my own kind of reinventing the wheel?
> (as I did previously?) drm_minor_register is called inside
> drm_dev_register so isn't leveraging existing drm_minor facilities
> much better solution?
Hm the previous version already dropped out of my inbox, so hard to find
it again. And I couldn't find this in archieves. Do you have pointers?
I thought the previous version did cgroup init separately from drm_device
setup, and I guess I suggested that it should be moved int
drm_dev_register/unregister?
Anyway, I don't think reusing the drm_minor registration makes sense,
since we want to be on the drm_device, not on the minor. Which is a bit
awkward for cgroups, which wants to identify devices using major.minor
pairs. But I guess drm is the first subsystem where 1 device can be
exposed through multiple minors ...
Tejun, any suggestions on this?
Anyway, I think just leveraging existing code because it can be abused to
make it fit for us doesn't make sense. E.g. for the kms side we also don't
piggy-back on top of drm_minor_register (it would be technically
possible), but instead we have drm_modeset_register_all().
-Daniel
>
> Kenny
>
> >
> >
> > >
> > > Kenny
> > >
> > > > -Daniel
> > > >
> > > > > ---
> > > > > drivers/gpu/drm/drm_drv.c | 19 +++++++++++++++++++
> > > > > drivers/gpu/drm/drm_internal.h | 4 ----
> > > > > include/drm/drm_drv.h | 4 ++++
> > > > > 3 files changed, 23 insertions(+), 4 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> > > > > index 862621494a93..000cddabd970 100644
> > > > > --- a/drivers/gpu/drm/drm_drv.c
> > > > > +++ b/drivers/gpu/drm/drm_drv.c
> > > > > @@ -254,11 +254,13 @@ struct drm_minor *drm_minor_acquire(unsigned int minor_id)
> > > > >
> > > > > return minor;
> > > > > }
> > > > > +EXPORT_SYMBOL(drm_minor_acquire);
> > > > >
> > > > > void drm_minor_release(struct drm_minor *minor)
> > > > > {
> > > > > drm_dev_put(minor->dev);
> > > > > }
> > > > > +EXPORT_SYMBOL(drm_minor_release);
> > > > >
> > > > > /**
> > > > > * DOC: driver instance overview
> > > > > @@ -1078,6 +1080,23 @@ int drm_dev_set_unique(struct drm_device *dev, const char *name)
> > > > > }
> > > > > EXPORT_SYMBOL(drm_dev_set_unique);
> > > > >
> > > > > +/**
> > > > > + * drm_minor_for_each - Iterate through all stored DRM minors
> > > > > + * @fn: Function to be called for each pointer.
> > > > > + * @data: Data passed to callback function.
> > > > > + *
> > > > > + * The callback function will be called for each @drm_minor entry, passing
> > > > > + * the minor, the entry and @data.
> > > > > + *
> > > > > + * If @fn returns anything other than %0, the iteration stops and that
> > > > > + * value is returned from this function.
> > > > > + */
> > > > > +int drm_minor_for_each(int (*fn)(int id, void *p, void *data), void *data)
> > > > > +{
> > > > > + return idr_for_each(&drm_minors_idr, fn, data);
> > > > > +}
> > > > > +EXPORT_SYMBOL(drm_minor_for_each);
> > > > > +
> > > > > /*
> > > > > * DRM Core
> > > > > * The DRM core module initializes all global DRM objects and makes them
> > > > > diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
> > > > > index e19ac7ca602d..6bfad76f8e78 100644
> > > > > --- a/drivers/gpu/drm/drm_internal.h
> > > > > +++ b/drivers/gpu/drm/drm_internal.h
> > > > > @@ -54,10 +54,6 @@ void drm_prime_destroy_file_private(struct drm_prime_file_private *prime_fpriv);
> > > > > void drm_prime_remove_buf_handle_locked(struct drm_prime_file_private *prime_fpriv,
> > > > > struct dma_buf *dma_buf);
> > > > >
> > > > > -/* drm_drv.c */
> > > > > -struct drm_minor *drm_minor_acquire(unsigned int minor_id);
> > > > > -void drm_minor_release(struct drm_minor *minor);
> > > > > -
> > > > > /* drm_vblank.c */
> > > > > void drm_vblank_disable_and_save(struct drm_device *dev, unsigned int pipe);
> > > > > void drm_vblank_cleanup(struct drm_device *dev);
> > > > > diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
> > > > > index 68ca736c548d..24f8d054c570 100644
> > > > > --- a/include/drm/drm_drv.h
> > > > > +++ b/include/drm/drm_drv.h
> > > > > @@ -799,5 +799,9 @@ static inline bool drm_drv_uses_atomic_modeset(struct drm_device *dev)
> > > > >
> > > > > int drm_dev_set_unique(struct drm_device *dev, const char *name);
> > > > >
> > > > > +int drm_minor_for_each(int (*fn)(int id, void *p, void *data), void *data);
> > > > > +
> > > > > +struct drm_minor *drm_minor_acquire(unsigned int minor_id);
> > > > > +void drm_minor_release(struct drm_minor *minor);
> > > > >
> > > > > #endif
> > > > > --
> > > > > 2.22.0
> > > > >
> > > >
> > > > --
> > > > Daniel Vetter
> > > > Software Engineer, Intel Corporation
> > > > http://blog.ffwll.ch
> >
> >
> >
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > +41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
next prev parent reply other threads:[~2019-09-04 8:54 UTC|newest]
Thread overview: 73+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-29 6:05 [PATCH RFC v4 00/16] new cgroup controller for gpu/drm subsystem Kenny Ho
2019-08-29 6:05 ` [PATCH RFC v4 02/16] cgroup: Introduce cgroup for drm subsystem Kenny Ho
[not found] ` <20190829060533.32315-3-Kenny.Ho-5C7GfCeVMHo@public.gmane.org>
2019-10-01 14:31 ` Michal Koutný
[not found] ` <20191001143106.GA4749-9OudH3eul5jcvrawFnH+a6VXKuFTiq87@public.gmane.org>
2019-11-29 6:00 ` Kenny Ho
2019-11-29 6:00 ` Kenny Ho
2019-12-02 19:14 ` Tejun Heo
2019-08-29 6:05 ` [PATCH RFC v4 03/16] drm, cgroup: Initialize drmcg properties Kenny Ho
2019-08-29 6:05 ` [PATCH RFC v4 07/16] drm, cgroup: Add total GEM buffer allocation limit Kenny Ho
[not found] ` <20190829060533.32315-8-Kenny.Ho-5C7GfCeVMHo@public.gmane.org>
2019-10-01 14:30 ` Michal Koutný
2019-11-29 7:18 ` Kenny Ho
2019-11-29 7:18 ` Kenny Ho
[not found] ` <20190829060533.32315-1-Kenny.Ho-5C7GfCeVMHo@public.gmane.org>
2019-08-29 6:05 ` [PATCH RFC v4 05/16] drm, cgroup: Add peak GEM buffer allocation stats Kenny Ho
2019-08-29 6:05 ` [PATCH RFC v4 08/16] drm, cgroup: Add peak GEM buffer allocation limit Kenny Ho
2019-08-29 6:05 ` [PATCH RFC v4 09/16] drm, cgroup: Add TTM buffer allocation stats Kenny Ho
2019-08-29 6:05 ` [PATCH RFC v4 10/16] drm, cgroup: Add TTM buffer peak usage stats Kenny Ho
2019-08-29 6:05 ` [PATCH RFC v4 11/16] drm, cgroup: Add per cgroup bw measure and control Kenny Ho
[not found] ` <20190829060533.32315-12-Kenny.Ho-5C7GfCeVMHo@public.gmane.org>
2019-10-01 14:30 ` Michal Koutný
2019-08-29 6:05 ` [PATCH RFC v4 13/16] drm, cgroup: Allow more aggressive memory reclaim Kenny Ho
2019-08-29 7:08 ` Koenig, Christian
2019-08-29 14:07 ` Kenny Ho
[not found] ` <CAOWid-dzJiqjH9+=36fFYh87OKOzToMDcJZpepOWdjoXpBSF8A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-08-29 14:12 ` Koenig, Christian
[not found] ` <f6963293-bebe-0dca-b509-799f9096ca91-5C7GfCeVMHo@public.gmane.org>
2019-08-29 14:39 ` Kenny Ho
2019-08-29 6:05 ` [PATCH RFC v4 15/16] drm, cgroup: add update trigger after limit change Kenny Ho
2019-08-31 4:28 ` [PATCH RFC v4 00/16] new cgroup controller for gpu/drm subsystem Tejun Heo
[not found] ` <20190831042857.GD2263813-LpCCV3molIbIZ9tKgghJQw2O0Ztt9esIQQ4Iyu8u01E@public.gmane.org>
2019-09-03 7:55 ` Daniel Vetter
[not found] ` <20190903075550.GJ2112-dv86pmgwkMBes7Z6vYuT8azUEOm+Xw19@public.gmane.org>
2019-09-03 18:50 ` Tejun Heo
2019-09-03 19:23 ` Kenny Ho
2019-09-03 19:48 ` Daniel Vetter
[not found] ` <CAKMK7uE5Bj-3cJH895iqnLpwUV+GBDM1Y=n4Z4A3xervMdJKXg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-09-06 15:23 ` Tejun Heo
[not found] ` <20190906152320.GM2263813-LpCCV3molIbIZ9tKgghJQw2O0Ztt9esIQQ4Iyu8u01E@public.gmane.org>
2019-09-06 15:34 ` Daniel Vetter
[not found] ` <CAKMK7uEXP7XLFB2aFU6+E0TH_DepFRkfCoKoHwkXtjZRDyhHig-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-09-06 15:45 ` Tejun Heo
[not found] ` <20190906154539.GP2263813-LpCCV3molIbIZ9tKgghJQw2O0Ztt9esIQQ4Iyu8u01E@public.gmane.org>
2019-09-10 11:54 ` Michal Hocko
[not found] ` <20190910115448.GT2063-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2019-09-10 16:03 ` Tejun Heo
2019-09-10 17:25 ` Michal Hocko
2019-09-17 12:21 ` Daniel Vetter
2019-08-29 6:05 ` [PATCH RFC v4 12/16] drm, cgroup: Add soft VRAM limit Kenny Ho
2019-08-29 6:05 ` [PATCH RFC v4 14/16] drm, cgroup: Introduce lgpu as DRM cgroup resource Kenny Ho
[not found] ` <20190829060533.32315-15-Kenny.Ho-5C7GfCeVMHo@public.gmane.org>
2019-10-08 18:53 ` Kuehling, Felix
[not found] ` <b3d2b3c1-8854-10ca-3e39-b3bef35bdfa9-5C7GfCeVMHo@public.gmane.org>
2019-10-09 10:31 ` Daniel Vetter
[not found] ` <20191009103153.GU16989-dv86pmgwkMBes7Z6vYuT8azUEOm+Xw19@public.gmane.org>
2019-10-09 15:08 ` Kenny Ho
[not found] ` <CAOWid-fLurBT6-h5WjQsEPA+dq1fgfWztbyZuLV4ypmWH8SC9w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-10-09 15:23 ` Daniel Vetter
2019-10-09 15:25 ` Kuehling, Felix
[not found] ` <ee873e89-48fd-c4c9-1ce0-73965f4ad2ba-5C7GfCeVMHo@public.gmane.org>
2019-10-09 15:34 ` Daniel Vetter
[not found] ` <20191009153429.GI16989-dv86pmgwkMBes7Z6vYuT8azUEOm+Xw19@public.gmane.org>
2019-10-09 15:53 ` Kuehling, Felix
[not found] ` <c7812af4-7ec4-02bb-ff4c-21dd114cf38e-5C7GfCeVMHo@public.gmane.org>
2019-10-09 16:06 ` Daniel Vetter
2019-10-09 18:52 ` Greathouse, Joseph
[not found] ` <CY4PR12MB17670EE9EE4A22663EB584E8F9950-rpdhrqHFk07NeWpHaHeGuQdYzm3356FpvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
2019-10-09 19:07 ` Daniel Vetter
2019-10-11 17:12 ` tj
2019-11-29 20:10 ` Felix Kuehling
2019-08-29 6:05 ` [PATCH RFC v4 16/16] drm/amdgpu: Integrate with DRM cgroup Kenny Ho
[not found] ` <20190829060533.32315-17-Kenny.Ho-5C7GfCeVMHo@public.gmane.org>
2019-10-08 19:11 ` Kuehling, Felix
[not found] ` <04abdc58-ae30-a13d-e7dc-f1020a1400b9-5C7GfCeVMHo@public.gmane.org>
2019-11-29 5:59 ` Kenny Ho
2019-11-29 5:59 ` Kenny Ho
2019-12-02 22:05 ` Greathouse, Joseph
2019-12-03 16:02 ` Kenny Ho
2019-09-03 8:02 ` [PATCH RFC v4 00/16] new cgroup controller for gpu/drm subsystem Daniel Vetter
[not found] ` <20190903080217.GL2112-dv86pmgwkMBes7Z6vYuT8azUEOm+Xw19@public.gmane.org>
2019-09-03 8:24 ` Koenig, Christian
2019-09-03 9:19 ` Daniel Vetter
2019-09-03 19:30 ` Kenny Ho
[not found] ` <20190829060533.32315-2-Kenny.Ho@amd.com>
[not found] ` <20190903075719.GK2112@phenom.ffwll.local>
2019-09-03 19:45 ` [PATCH RFC v4 01/16] drm: Add drm_minor_for_each Kenny Ho
[not found] ` <CAOWid-dxxDhyxP2+0R0oKAk29rR-1TbMyhshR1+gbcpGJCAW6g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-09-03 20:12 ` Daniel Vetter
[not found] ` <CAKMK7uEofjdVURu+meonh_YdV5eX8vfNALkW3A_+kLapCV8j+w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-09-03 20:43 ` Kenny Ho
[not found] ` <CAOWid-eUVztW4hNVpznnJRcwHcjCirGL2aS75p4OY8XoGuJqUg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-09-04 8:54 ` Daniel Vetter [this message]
[not found] ` <20190904085434.GF2112-dv86pmgwkMBes7Z6vYuT8azUEOm+Xw19@public.gmane.org>
2019-09-05 18:27 ` Kenny Ho
2019-09-05 18:28 ` Kenny Ho
2019-09-05 20:06 ` Daniel Vetter
[not found] ` <CAKMK7uGSrscs-WAv0pYfcxaUGXvx7M6JYbiPHTY=1hxRbFK1sg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-09-05 20:20 ` Kenny Ho
2019-09-05 20:32 ` Daniel Vetter
[not found] ` <CAKMK7uHy+GRAcpLDuz6STCBW+GNfNWr-i=ZERF3uqkO7jfynnQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-09-05 21:26 ` Kenny Ho
[not found] ` <CAOWid-cRP1T2gr2U_ZN+QhS7jFM0kFTWiYy8JPPXXmGW7xBPzA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-09-06 9:12 ` Daniel Vetter
2019-09-06 15:29 ` Tejun Heo
2019-09-06 15:36 ` Daniel Vetter
[not found] ` <CAKMK7uFQqAMB1DbiEy-o2bzr_F25My93imNcg1Qh9DHe=uWQug-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-09-06 15:38 ` 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=20190904085434.GF2112@phenom.ffwll.local \
--to=daniel-/w4ywyx8dfk@public.gmane.org \
--cc=Kenny.Ho-5C7GfCeVMHo@public.gmane.org \
--cc=alexander.deucher-5C7GfCeVMHo@public.gmane.org \
--cc=amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
--cc=cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=christian.koenig-5C7GfCeVMHo@public.gmane.org \
--cc=dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
--cc=felix.kuehling-5C7GfCeVMHo@public.gmane.org \
--cc=joseph.greathouse-5C7GfCeVMHo@public.gmane.org \
--cc=jsparks-WVYJKLFxKCc@public.gmane.org \
--cc=lkaplan-WVYJKLFxKCc@public.gmane.org \
--cc=tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=y2kenny-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.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