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: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
	Alexei Starovoitov <alexei.starovoitov@gmail.com>,
	cgroups@vger.kernel.org, kernel-team@fb.com,
	Roman Gushchin <guro@fb.com>
Subject: Re: [PATCH v3 1/6] cgroup: Allow registration and lookup of cgroup private data
Date: Tue, 13 Mar 2018 13:50:35 -0700	[thread overview]
Message-ID: <20180313205035.GN2943022@devbig577.frc2.facebook.com> (raw)
In-Reply-To: <20180306234700.6562-2-matthew.d.roper@intel.com>

Hello, Matt.

cc'ing Roman and Alexei.

On Tue, Mar 06, 2018 at 03:46:55PM -0800, Matt Roper wrote:
> There are cases where other parts of the kernel may wish to store data
> associated with individual cgroups without building a full cgroup
> controller.  Let's add interfaces to allow them to register and lookup
> this private data for individual cgroups.
> 
> A kernel system (e.g., a driver) that wishes to register private data
> for a cgroup will do so by subclassing the 'struct cgroup_priv'
> structure to describe the necessary data to store.  Before registering a
> private data structure to a cgroup, the caller should fill in the 'key'
> and 'free' fields of the base cgroup_priv structure.
> 
>  * 'key' should be a unique void* that will act as a key for future
>    privdata lookups/removals.  Note that this allows drivers to store
>    per-device private data for a cgroup by using a device pointer as a key.
> 
>  * 'free' should be a function pointer to a function that may be used
>    to destroy the private data.  This function will be called
>    automatically if the underlying cgroup is destroyed.

This feature turned out to have more users than I originally
anticipated and bpf also wants something like this to track network
states.  The requirements are pretty similar but not quite the same.
The extra requirements are...

* Lookup must be really cheap.  Probably using pointer hash or walking
  list isn't great, so maybe idr based lookup + RCU protected index
  table per cgroup?

* It should support both regular memory and percpu pointers.  Given
  that what cgroup does is pretty much cgroup:key -> pointer lookup,
  it's mostly about getting the interface right so that it's not too
  error-prone.

Sorry about moving the goalpost.

Thanks.

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

  reply	other threads:[~2018-03-13 20:50 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-06 23:46 [PATCH v3 0/6] DRM/i915 cgroup integration Matt Roper
2018-03-06 23:46 ` [PATCH v3 1/6] cgroup: Allow registration and lookup of cgroup private data Matt Roper
2018-03-13 20:50   ` Tejun Heo [this message]
2018-03-13 21:27     ` Alexei Starovoitov
2018-03-13 21:37       ` Roman Gushchin
2018-03-13 21:47         ` Alexei Starovoitov
2018-03-13 22:09           ` Roman Gushchin
2018-03-13 22:13           ` Tejun Heo
2018-03-13 22:42             ` Alexei Starovoitov
2018-03-13 22:52               ` Roman Gushchin
2018-03-06 23:46 ` [PATCH v3 2/6] cgroup: Introduce task_get_dfl_cgroup() Matt Roper
2018-03-13 20:41   ` Tejun Heo
2018-03-06 23:46 ` [PATCH v3 3/6] cgroup: Introduce cgroup_permission() Matt Roper
2018-03-13 20:43   ` Tejun Heo
2018-03-06 23:46 ` [PATCH v3 4/6] drm/i915: cgroup integration (v2) Matt Roper
2018-03-06 23:46 ` [PATCH v3 5/6] drm/i915: Introduce 'priority offset' for GPU contexts (v2) Matt Roper
2018-03-08 11:32   ` Chris Wilson
2018-03-08 13:11     ` Chris Wilson
2018-03-08 18:22       ` Matt Roper
2018-03-08 18:48         ` Chris Wilson
2018-03-08 18:55           ` Chris Wilson
2018-03-08 19:31             ` Matt Roper
2018-03-06 23:47 ` [PATCH v3 6/6] drm/i915: Add context priority & priority offset to debugfs (v2) Matt Roper
2018-03-06 23:49 ` [PATCH i-g-t 1/2] tools: Introduce intel_cgroup tool Matt Roper
2018-03-06 23:49   ` [PATCH i-g-t 2/2] tests: Introduce drv_cgroup Matt Roper
2018-03-06 23:59 ` ✗ Fi.CI.SPARSE: warning for DRM/i915 cgroup integration Patchwork
2018-03-07  0:14 ` ✓ Fi.CI.BAT: success " Patchwork
2018-03-07  5:16 ` ✗ Fi.CI.IGT: failure " 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=20180313205035.GN2943022@devbig577.frc2.facebook.com \
    --to=tj@kernel.org \
    --cc=alexei.starovoitov@gmail.com \
    --cc=cgroups@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=guro@fb.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=kernel-team@fb.com \
    --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