[PATCH RFC v4 00/16] new cgroup controller for gpu/drm subsystem
tj at kernel.org
Tue Sep 3 18:50:13 UTC 2019
On Tue, Sep 03, 2019 at 09:55:50AM +0200, Daniel Vetter wrote:
> > * While breaking up and applying control to different types of
> > internal objects may seem attractive to folks who work day in and
> > day out with the subsystem, they aren't all that useful to users and
> > the siloed controls are likely to make the whole mechanism a lot
> > less useful. We had the same problem with cgroup1 memcg - putting
> > control of different uses of memory under separate knobs. It made
> > the whole thing pretty useless. e.g. if you constrain all knobs
> > tight enough to control the overall usage, overall utilization
> > suffers, but if you don't, you really don't have control over actual
> > usage. For memcg, what has to be allocated and controlled is
> > physical memory, no matter how they're used. It's not like you can
> > go buy more "socket" memory. At least from the looks of it, I'm
> > afraid gpu controller is repeating the same mistakes.
> We do have quite a pile of different memories and ranges, so I don't
> thinkt we're doing the same mistake here. But it is maybe a bit too
I see. One thing which caught my eyes was the system memory control.
Shouldn't that be controlled by memcg? Is there something special
about system memory used by gpus?
> complicated, and exposes stuff that most users really don't care about.
Could be from me not knowing much about gpus but definitely looks too
complex to me. I don't see how users would be able to alloate, vram,
system memory and GART with reasonable accuracy. memcg on cgroup2
deals with just single number and that's already plenty challenging.
More information about the dri-devel