All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.