From: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
To: Matt Roper <matthew.d.roper-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Cc: dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
intel-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH RFC v2 1/7] cgroup: Allow drivers to store data associated with a cgroup
Date: Wed, 7 Feb 2018 14:11:57 -0800 [thread overview]
Message-ID: <20180207221157.GJ695913@devbig577.frc2.facebook.com> (raw)
In-Reply-To: <20180201195315.4956-2-matthew.d.roper-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Hello,
On Thu, Feb 01, 2018 at 11:53:09AM -0800, Matt Roper wrote:
> * Drivers may be built as modules (and unloaded/reloaded) which is not
> something cgroup controllers support today.
As discussed in the other subthread, this shouldn't be a concern.
> * Drivers may wish to provide their own interface to allow userspace to
> adjust driver-specific settings (e.g., via a driver ioctl rather than
> via the kernfs filesystem).
> * A single driver may be managing multiple devices and wish to maintain
> different driver-specific cgroup data for each.
If you look at io and rdma controllers, they already do this.
> Note that technically these interfaces aren't restricted to drivers
> (other non-driver parts of the kernel could make use of them as well).
> I expect drivers to be the primary consumers of this interface and
> couldn't think of a more appropriate generic name (the term "subsystem"
> would probably be more accurate, but that's already used by cgroup
> controllers).
Let's please not do "driver", it's really confusing. Just coming up
with a made-up word would be fine as long as the connection can be
made and the word is easily identifiable. e.g. cgroup cdata / pdata for
cgroup custom / priv data.
> +/*
> + * Driver-specific cgroup data. Drivers should subclass this structure with
> + * their own fields for data that should be stored alongside individual
> + * cgroups.
> + */
> +struct cgroup_driver_data {
> + /* Driver this data structure is associated with */
> + struct cgroup_driver *drv;
> +
> + /* Node in cgroup's data hashtable */
> + struct hlist_node cgroupnode;
> +
> + /* Node in driver's data list; used to cleanup on driver unload */
> + struct list_head drivernode;
> +};
...
> +struct cgroup_driver {
> + /* Functions this driver uses to manage its data */
> + struct cgroup_driver_funcs *funcs;
> +
> + /*
> + * List of driver-specific data structures that need to be cleaned up
> + * if driver is unloaded.
> + */
> + struct list_head datalist;
> +};
It generally looks great but can we do something like the following in
terms of interface?
struct cgroup_cdata {
const void *key;
void (*free)(struct cgroup_cdata *cdata);
/* whatever other necessary fields */
char data[];
};
int cgroup_cdata_install(struct cgroup *cgrp, struct cgroup_cdata *cdata);
struct cgroup_cdata *cgroup_cdata_lookup(struct cgroup *cgrp, const void *key);
int cgroup_cdata_free(struct cgroup *cgrp, const void *key);
/* free is also automatically called when the cgroup is released */
And please use a separate lock or mutex for managing them.
Thanks.
--
tejun
next prev parent reply other threads:[~2018-02-07 22:11 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 [this message]
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
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=20180207221157.GJ695913@devbig577.frc2.facebook.com \
--to=tj-dgejt+ai2ygdnm+yrofe0a@public.gmane.org \
--cc=cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
--cc=intel-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
--cc=matthew.d.roper-ral2JQCrhuEAvxtiuMwx3w@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