Hello, Daniel. 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. Thanks. -- tejun
