On Mon, Jan 25, 2021 at 1:35 PM Mike Rapoport [off-list ref] wrote:

On Mon, Jan 25, 2021 at 09:18:04AM -0800, Shakeel Butt wrote:

quoted

On Mon, Jan 25, 2021 at 8:20 AM Matthew Wilcox [off-list ref] wrote:

quoted

On Thu, Jan 21, 2021 at 02:27:20PM +0200, Mike Rapoport wrote:

quoted

From: Mike Rapoport <redacted>

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.

quoted

quoted

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.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel