On Mon, Jan 25, 2021 at 1:35 PM Mike Rapoport rppt@kernel.org 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@infradead.org wrote:
On Thu, Jan 21, 2021 at 02:27:20PM +0200, Mike Rapoport wrote:
From: Mike Rapoport rppt@linux.ibm.com
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.