Re: [PATCH 2/2] vmalloc: Account memcg per vmalloc

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Dec 11, 2024 at 11:09:56AM -0500, Johannes Weiner wrote:
> This would work, but it seems somewhat complicated. The atomics in
> memcg charging and the vmstat updates are batched, and the per-page
> overhead is for the most part cheap per-cpu ops. Not an issue per se.

OK, fair enough, I hadn't realised it was a percpu-refcount.  Still,
we might consume several batches (batch size of 64) when we could do it
all in one shot.

Perhaps you'd be more persuaded by:

(a) If we clear __GFP_ACCOUNT then alloc_pages_bulk() will work, and
that's a pretty significant performance win over calling alloc_pages()
in a loop.

(b) Once we get to memdescs, calling alloc_pages() with __GFP_ACCOUNT
set is going to require allocating a memdesc to store the obj_cgroup
in, so in the future we'll save an allocation.

Your proposed alternative will work and is way less churn.  But it's
not preparing us for memdescs ;-)




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]     [Monitors]

  Powered by Linux