On Mon, Jan 25, 2021 at 1:35 PM Mike Rapoport <rppt@xxxxxxxxxx> wrote: > > On Mon, Jan 25, 2021 at 09:18:04AM -0800, Shakeel Butt wrote: > > On Mon, Jan 25, 2021 at 8:20 AM Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote: > > > > > > On Thu, Jan 21, 2021 at 02:27:20PM +0200, Mike Rapoport wrote: > > > > From: Mike Rapoport <rppt@xxxxxxxxxxxxx> > > > > > > > > Account memory consumed by secretmem to memcg. The accounting is updated > > > > when the memory is actually allocated and freed. > > I though about doing per-page accounting, but then one would be able to > create a lot of secretmem file descriptors, use only a page from each while > actual memory consumption will be way higher. > > > > I think this is wrong. It fails to account subsequent allocators from > > > the same PMD. If you want to track like this, you need separate pools > > > per memcg. > > > > > > > Are these secretmem pools shared between different jobs/memcgs? > > A secretmem pool is per anonymous file descriptor and this file descriptor > can be shared only explicitly between several processes. So, the secretmem > pool should not be shared between different jobs/memcg. Of course, it's > possible to spread threads of a process across different memcgs, but in > that case the accounting will be similar to what's happening today with > sl*b. I don't think memcg accounting for sl*b works like that. > The first thread to cause kmalloc() will be charged for the > allocation of the entire slab and subsequent allocations from that slab > will not be accounted. The latest kernel does object level memcg accounting. So, each allocation from these threads will correctly charge their own memcgs.
