On Fri, May 02, 2025 at 01:35:59PM +1000, Dave Airlie wrote: > Hey all, > > This is my second attempt at adding the initial simple memcg/ttm > integration. > > This varies from the first attempt in two major ways: > > 1. Instead of using __GFP_ACCOUNT and direct calling kmem charges > for pool memory, and directly hitting the GPU statistic,
Why was the first attempt abandoned? What was the issue with the above approach? > Waiman > suggested I just do what the network socket stuff did, which looks > simpler. So this adds two new memcg apis that wrap accounting. > The pages no longer get assigned the memcg, it's owned by the > larger BO object which makes more sense. The issue with this approach is that this new stat is only exposed in memcg. For networking, there are interfaces like /proc/net/sockstat and /proc/net/protocols which expose system wide network memory usage. I think we should expose this new "memory used by gpus" at the system level possibly through /proc/meminfo. > > 2. Christian suggested moving it up a layer to avoid the pool business, > this was a bit tricky, since I want the gfp flags, but I think it only > needs some of them and it should work. One other big difference is that > I aligned it with the dmem interaction, where it tries to get space in > the memcg before it has even allocated any pages, I don't understand the memcg reference in the above statement. Dmem is a separate cgroup controller orthogonal to memcg. > I'm not 100% sure > this is how things should be done, but it was easier, so please let > me know if it is wrong. > > This still doesn't do anything with evictions except ignore them, > and I've some follows up on the old thread to discuss more on them. > > Dave. >
