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 agreed,

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, this

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] [RFC v3 00/12] DRM scheduling cgroup controller

2023-01-27 Thread Tvrtko Ursulin
On 27/01/2023 10:04, Michal Koutný wrote: 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 l

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

2023-01-26 Thread Tvrtko Ursulin
On 26/01/2023 17:57, Tvrtko Ursulin wrote: On 26/01/2023 17:04, Tejun Heo wrote: driver folks think about the current RFC tho. Is at least AMD on board with the approach? Yes I am keenly awaiting comments from the DRM colleagues as well. Forgot to mention one thing on this point which m

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

2023-01-26 Thread Tvrtko Ursulin
Hi, (Two replies in one, hope you will manage to navigate it.) On 26/01/2023 17:04, Tejun Heo wrote: Hello, On Thu, Jan 26, 2023 at 02:00:50PM +0100, Michal Koutný wrote: On Wed, Jan 25, 2023 at 06:11:35PM +, Tvrtko Ursulin wrote: I don't immediately see how you envisage the half-use

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

2023-01-26 Thread Tejun Heo
Hello, On Thu, Jan 26, 2023 at 02:00:50PM +0100, Michal Koutný wrote: > 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 b

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

2023-01-25 Thread Tvrtko Ursulin
Hi, On 23/01/2023 15:42, Michal Koutný wrote: Hello Tvrtko. Interesting work. Thanks! 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) i

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

2023-01-12 Thread Tvrtko Ursulin
From: Tvrtko Ursulin This series contains a proposal for a DRM scheduling cgroup controller which implements a weight based hierarchical GPU usage budget based controller similar in concept to some of the existing controllers. Motivation mostly comes from my earlier proposal where I identified t