Thread (78 messages) 78 messages, 10 authors, 2021-02-04

Re: [PATCH v16 08/11] secretmem: add memcg accounting

From: Mike Rapoport <rppt@kernel.org>
Date: 2021-01-25 21:56:53
Also in: linux-api, linux-arch, linux-fsdevel, linux-kselftest, linux-mm, linux-riscv, lkml, nvdimm

On Mon, Jan 25, 2021 at 09:18:04AM -0800, Shakeel Butt wrote:
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
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. 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.

That said, having a pool per memcg will add ton of complexity with very
dubious value.

-- 
Sincerely yours,
Mike.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help