On Tue, Apr 5, 2022 at 5:12 AM Michal Koutný <mkoutny@xxxxxxxx> wrote: > > On Fri, Apr 01, 2022 at 11:41:36AM -0700, "T.J. Mercier" <tjmercier@xxxxxxxxxx> wrote: > > This link doesn't work for me, but I think you're referring to the > > discussion about your "RAM_backed_buffers" comment from March 23rd. > > (Oops, it's a non-public message. But yes, you guessed it right ;-)) > > > Anyway the test I did goes like this: enable memcg and gpu cgoups > > tracking and run a process that allocates 100MiB of dmabufs. Observe > > memcg and gpu accounting values before and after the allocation. > > Thanks for this measurement/dem/demoo. > > > Before > > # cat memory.current gpu.memory.current > > 14909440 > > system 0 > > > > <Test program does the allocation of 100MiB of dmabufs> > > > > After > > # cat memory.current gpu.memory.current > > 48025600 > > system 104857600 > > > > So the memcg value increases by about 30 MiB while the gpu values > > increases by 100 MiB. > > > This is with kmem enabled, and the /proc/maps > > file for this process indicates that the majority of that 30 MiB is > > kernel memory. > > > I think this result shows that neither the kernel nor process memory > > overlap with the gpu cgroup tracking of these allocations. > > It depends how the semantics of the 'system' entry is defined, no? > As I grasped from other thread, the 'total' is going to be removed, so > 'system' represents exclusively device memory? > That's right. The system charges (soon to be renamed "system-heap") result only from an allocator (in this case the system heap) deciding to call gpucg_try_charge for the buffer which is entirely device memory. > > > So despite the fact that these buffers are in main memory, they are > > allocated in a way that does not result in memcg attribution. (It > > looks to me like __GFP_ACCOUNT is not set for these.) > > (I thought you knew what dmabufs your program used :-p) > I'm coming up to speed on a lot of new-to-me code here. :) Just for completeness, these buffers were allocated with libdmabufheap's AllocSystem. > So, the goal is to do the tracking and migrations only via the gpu cg > layer, regardless how memcg charges it (or not). > > (I have no opinion on that, I'm just summing it so that we're on the > same page.) > Yes, this reflects my intention and current state of the code in this series. > Michal Thanks, T.J.
