Re: [RFC 1/8] cgroup: Add the DRM cgroup controller

2024-02-07 Thread Michal Koutný
Hello. On Tue, Oct 24, 2023 at 05:07:20PM +0100, Tvrtko Ursulin wrote: > +struct drm_cgroup_state { > + struct cgroup_subsys_state css; > +}; > + > +struct drm_root_cgroup_state { > + struct drm_cgroup_state drmcs; > +}; > + > +static struct drm_root_cgroup_state root_drmcs; Special

Re: [RFC 6/8] cgroup/drm: Introduce weight based drm cgroup control

2024-02-07 Thread Michal Koutný
Hello. (I hope I'm replying to the latest iteration and it has some validitiy still. Sorry for my late reply. Few points caught my attention.) On Tue, Oct 24, 2023 at 05:07:25PM +0100, Tvrtko Ursulin wrote: > @@ -15,10 +17,28 @@ struct drm_cgroup_state { > struct cgroup_subsys_state css;

Re: [Intel-gfx] [RFC 10/12] cgroup/drm: Introduce weight based drm cgroup control

2023-02-02 Thread Michal Koutný
On Thu, Jan 12, 2023 at 04:56:07PM +, Tvrtko Ursulin wrote: > +static int drmcs_can_attach(struct cgroup_taskset *tset) > +{ > + int ret; > + > + /* > + * As processes are getting moved between groups we need to ensure > + * both that the old group does not see a sudden

Re: [Intel-gfx] [RFC v3 00/12] DRM scheduling cgroup controller

2023-02-02 Thread Michal Koutný
On Thu, Jan 26, 2023 at 05:57:24PM +, Tvrtko Ursulin wrote: > So even if the RFC shows just a simple i915 implementation, the controller > itself shouldn't prevent a smarter approach (via exposed ABI). scan/query + over budget notification is IMO limited in guarantees. > [...] > Yes

Re: [Intel-gfx] [RFC 10/12] cgroup/drm: Introduce weight based drm cgroup control

2023-02-02 Thread Michal Koutný
On Fri, Jan 27, 2023 at 01:31:54PM +, Tvrtko Ursulin wrote: > I think you missed the finish_suspend_scanning() part: > > if (root_drmcs.suspended_period_us) > cancel_delayed_work_sync(_drmcs.scan_work); > > So if scanning was in progress migration will wait until it

Re: [Intel-gfx] [RFC v3 00/12] DRM scheduling cgroup controller

2023-02-02 Thread Michal Koutný
On Fri, Jan 27, 2023 at 11:40:58AM +, Tvrtko Ursulin wrote: > The main point is, should someone prove me wrong and come up a smarter way > at some point in the future, then "drm.weight" as an ABI remains compatible > and the improvement can happen completely under the hood. In the mean time

Re: [Intel-gfx] [RFC v3 00/12] DRM scheduling cgroup controller

2023-02-02 Thread Michal Koutný
Hello Tvrtko. Interesting work. On Thu, Jan 12, 2023 at 04:55:57PM +, Tvrtko Ursulin wrote: > Because of the heterogenous hardware and driver DRM capabilities, soft limits > are implemented as a loose co-operative (bi-directional) interface between the > controller and DRM core. IIUC,

Re: [Intel-gfx] [RFC v3 00/12] DRM scheduling cgroup controller

2023-02-02 Thread Michal Koutný
On Wed, Jan 25, 2023 at 06:11:35PM +, Tvrtko Ursulin wrote: > I don't immediately see how you envisage the half-userspace implementation > would look like in terms of what functionality/new APIs would be provided by > the kernel? Output: drm.stat (with consumed time(s)) Input:

Re: [Intel-gfx] [PATCH 06/11] cgroup: fix -Wzero-length-bounds warnings

2021-03-31 Thread Michal Koutný
On Tue, Mar 30, 2021 at 11:00:36AM +0200, Arnd Bergmann wrote: > Would it be possible to enclose most or all of kernel/cgroup/cgroup.c > in an #ifdef CGROUP_SUBSYS_COUNT block? Even without any controllers, there can still be named hierarchies (v1) or the default hierarchy (v2) (for instance) for

Re: [Intel-gfx] [PATCH 06/11] cgroup: fix -Wzero-length-bounds warnings

2021-03-30 Thread Michal Koutný
viewed-by: Michal Koutný signature.asc Description: Digital signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx