From: Balbir Singh <balbirs@nvidia.com>
To: "Matthew Wilcox (Oracle)" <willy@infradead.org>,
Andrew Morton <akpm@linux-foundation.org>
Cc: Christoph Hellwig <hch@lst.de>,
linux-mm@kvack.org, Johannes Weiner <hannes@cmpxchg.org>,
Michal Hocko <mhocko@kernel.org>,
Roman Gushchin <roman.gushchin@linux.dev>,
Shakeel Butt <shakeel.butt@linux.dev>,
Muchun Song <muchun.song@linux.dev>,
cgroups@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH] vmalloc: Move memcg logic into memcg code
Date: Wed, 11 Dec 2024 22:44:51 +1100 [thread overview]
Message-ID: <36e2b7d0-6a48-4ad3-9f1d-bf0a7ee10c0c@nvidia.com> (raw)
In-Reply-To: <20241210193035.2667005-1-willy@infradead.org>
On 12/11/24 06:30, Matthew Wilcox (Oracle) wrote:
> Today we account each page individually to the memcg, which works well
> enough, if a little inefficiently (N atomic operations per page instead
> of N per allocation). Unfortunately, the stats can get out of sync when
> i915 calls vmap() with VM_MAP_PUT_PAGES. The pages being passed were not
> allocated by vmalloc, so the MEMCG_VMALLOC counter was never incremented.
> But it is decremented when the pages are freed with vfree().
>
> Solve all of this by tracking the memcg at the vm_struct level.
> This logic has to live in the memcontrol file as it calls several
> functions which are currently static.
>
> Fixes: b944afc9d64d (mm: add a VM_MAP_PUT_PAGES flag for vmap)
> Cc: stable@vger.kernel.org
> Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
> ---
> include/linux/memcontrol.h | 7 ++++++
> include/linux/vmalloc.h | 3 +++
> mm/memcontrol.c | 46 ++++++++++++++++++++++++++++++++++++++
> mm/vmalloc.c | 14 ++++++------
> 4 files changed, 63 insertions(+), 7 deletions(-)
>
> diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
> index 5502aa8e138e..83ebcadebba6 100644
> --- a/include/linux/memcontrol.h
> +++ b/include/linux/memcontrol.h
> @@ -1676,6 +1676,10 @@ static inline struct obj_cgroup *get_obj_cgroup_from_current(void)
>
> int obj_cgroup_charge(struct obj_cgroup *objcg, gfp_t gfp, size_t size);
> void obj_cgroup_uncharge(struct obj_cgroup *objcg, size_t size);
> +int obj_cgroup_charge_vmalloc(struct obj_cgroup **objcgp,
> + unsigned int nr_pages, gfp_t gfp);
> +void obj_cgroup_uncharge_vmalloc(struct obj_cgroup *objcgp,
> + unsigned int nr_pages);
>
> extern struct static_key_false memcg_bpf_enabled_key;
> static inline bool memcg_bpf_enabled(void)
> @@ -1756,6 +1760,9 @@ static inline void __memcg_kmem_uncharge_page(struct page *page, int order)
> {
> }
>
> +/* Must be macros to avoid dereferencing objcg in vm_struct */
> +#define obj_cgroup_charge_vmalloc(objcgp, nr_pages, gfp) 0
> +#define obj_cgroup_uncharge_vmalloc(objcg, nr_pages) do { } while (0)
> static inline struct obj_cgroup *get_obj_cgroup_from_folio(struct folio *folio)
> {
> return NULL;
> diff --git a/include/linux/vmalloc.h b/include/linux/vmalloc.h
> index 31e9ffd936e3..ec7c2d607382 100644
> --- a/include/linux/vmalloc.h
> +++ b/include/linux/vmalloc.h
> @@ -60,6 +60,9 @@ struct vm_struct {
> #endif
> unsigned int nr_pages;
> phys_addr_t phys_addr;
> +#ifdef CONFIG_MEMCG
> + struct obj_cgroup *objcg;
> +#endif
> const void *caller;
> };
>
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 7b3503d12aaf..629bffc3e26d 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -5472,4 +5472,50 @@ static int __init mem_cgroup_swap_init(void)
> }
> subsys_initcall(mem_cgroup_swap_init);
>
> +/**
> + * obj_cgroup_charge_vmalloc - Charge vmalloc memory
> + * @objcgp: Pointer to an object cgroup
> + * @nr_pages: Number of pages
> + * @gfp: Memory allocation flags
> + *
> + * Return: 0 on success, negative errno on failure.
> + */
> +int obj_cgroup_charge_vmalloc(struct obj_cgroup **objcgp,
> + unsigned int nr_pages, gfp_t gfp)
> +{
> + struct obj_cgroup *objcg;
> + int err;
Are we also responsible for setting *objcgp to NULL for return
conditions (when we return before setting it)?
> +
> + if (mem_cgroup_disabled() || !(gfp & __GFP_ACCOUNT))
> + return 0;
Don't we want !memcg_kmem_online() instead of mem_cgroup_disabled()?
> +
> + objcg = current_obj_cgroup();
> + if (!objcg)
> + return 0;
> +
> + err = obj_cgroup_charge_pages(objcg, gfp, nr_pages);
> + if (err)
> + return err;
> + obj_cgroup_get(objcg);
> + mod_memcg_state(obj_cgroup_memcg(objcg), MEMCG_VMALLOC, nr_pages);
> + *objcgp = objcg;
> +
> + return 0;
> +}
<snip>
Balbir Singh
next prev parent reply other threads:[~2024-12-11 11:45 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-10 19:30 [PATCH] vmalloc: Move memcg logic into memcg code Matthew Wilcox (Oracle)
2024-12-10 20:05 ` Matthew Wilcox
2024-12-11 10:11 ` kernel test robot
2024-12-11 11:44 ` Balbir Singh [this message]
2024-12-11 19:14 ` kernel test robot
2024-12-11 23:26 ` kernel test robot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=36e2b7d0-6a48-4ad3-9f1d-bf0a7ee10c0c@nvidia.com \
--to=balbirs@nvidia.com \
--cc=akpm@linux-foundation.org \
--cc=cgroups@vger.kernel.org \
--cc=hannes@cmpxchg.org \
--cc=hch@lst.de \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=muchun.song@linux.dev \
--cc=roman.gushchin@linux.dev \
--cc=shakeel.butt@linux.dev \
--cc=stable@vger.kernel.org \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.