From: Vlastimil Babka <vbabka@suse.cz>
To: Shakeel Butt <shakeel.butt@linux.dev>,
Andrew Morton <akpm@linux-foundation.org>
Cc: Yosry Ahmed <yosryahmed@google.com>,
Roman Gushchin <roman.gushchin@linux.dev>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Meta kernel team <kernel-team@meta.com>
Subject: Re: [PATCH] memcg: slub: fix SUnreclaim for post charged objects
Date: Tue, 10 Dec 2024 09:29:59 +0100 [thread overview]
Message-ID: <5a047afd-1e9f-4e68-8c8a-d5b0b5506bb3@suse.cz> (raw)
In-Reply-To: <20241210040657.3441287-1-shakeel.butt@linux.dev>
On 12/10/24 05:06, Shakeel Butt wrote:
> Large kmalloc directly allocates from the page allocator and then use
> lruvec_stat_mod_folio() to increment the unreclaimable slab stats for
> global and memcg. However when post memcg charging of slab objects was
> added in commit 9028cdeb38e1 ("memcg: add charging of already allocated
> slab objects"), it missed to correctly handle the unreclaimable slab
> stats for memcg.
>
> One user visisble effect of that bug is that the node level
> unreclaimable slab stat will work correctly but the memcg level stat can
> underflow as kernel correctly handles the free path but the charge path
> missed to increment the memcg level unreclaimable slab stat. Let's fix
> by correctly handle in the post charge code path.
>
> Fixes: 9028cdeb38e1 ("memcg: add charging of already allocated slab objects")
That's a 6.12-rc1 commit so I'm adding cc stable.
> Signed-off-by: Shakeel Butt <shakeel.butt@linux.dev>
Queued in slab/for-next-fixes, thanks!
Vlastimil
> ---
> mm/slub.c | 21 ++++++++++++++++++---
> 1 file changed, 18 insertions(+), 3 deletions(-)
>
> diff --git a/mm/slub.c b/mm/slub.c
> index f62c829b7b6b..88bf2bf51bd6 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -2189,9 +2189,24 @@ bool memcg_slab_post_charge(void *p, gfp_t flags)
>
> folio = virt_to_folio(p);
> if (!folio_test_slab(folio)) {
> - return folio_memcg_kmem(folio) ||
> - (__memcg_kmem_charge_page(folio_page(folio, 0), flags,
> - folio_order(folio)) == 0);
> + int size;
> +
> + if (folio_memcg_kmem(folio))
> + return true;
> +
> + if (__memcg_kmem_charge_page(folio_page(folio, 0), flags,
> + folio_order(folio)))
> + return false;
> +
> + /*
> + * This folio has already been accounted in the global stats but
> + * not in the memcg stats. So, subtract from the global and use
> + * the interface which adds to both global and memcg stats.
> + */
> + size = folio_size(folio);
> + node_stat_mod_folio(folio, NR_SLAB_UNRECLAIMABLE_B, -size);
> + lruvec_stat_mod_folio(folio, NR_SLAB_UNRECLAIMABLE_B, size);
> + return true;
> }
>
> slab = folio_slab(folio);
prev parent reply other threads:[~2024-12-10 8:30 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-10 4:06 Shakeel Butt
2024-12-10 8:29 ` Vlastimil Babka [this message]
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=5a047afd-1e9f-4e68-8c8a-d5b0b5506bb3@suse.cz \
--to=vbabka@suse.cz \
--cc=akpm@linux-foundation.org \
--cc=kernel-team@meta.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=roman.gushchin@linux.dev \
--cc=shakeel.butt@linux.dev \
--cc=yosryahmed@google.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®