From: Frank van der Linden <fvdl@google.com>
To: Nhat Pham <nphamcs@gmail.com>
Cc: akpm@linux-foundation.org, riel@surriel.com, hannes@cmpxchg.org,
mhocko@kernel.org, roman.gushchin@linux.dev,
shakeelb@google.com, muchun.song@linux.dev, tj@kernel.org,
lizefan.x@bytedance.com, shuah@kernel.org,
mike.kravetz@oracle.com, yosryahmed@google.com,
linux-mm@kvack.org, kernel-team@meta.com,
linux-kernel@vger.kernel.org, cgroups@vger.kernel.org
Subject: Re: [PATCH 0/2] hugetlb memcg accounting
Date: Tue, 26 Sep 2023 13:50:10 -0700 [thread overview]
Message-ID: <CAPTztWY8eDSa1qKx35hTm5ef+e13SDnRHDrevc-1V1v7-pEP3w@mail.gmail.com> (raw)
In-Reply-To: <20230926194949.2637078-1-nphamcs@gmail.com>
On Tue, Sep 26, 2023 at 12:49 PM Nhat Pham <nphamcs@gmail.com> wrote:
>
> Currently, hugetlb memory usage is not acounted for in the memory
> controller, which could lead to memory overprotection for cgroups with
> hugetlb-backed memory. This has been observed in our production system.
>
> This patch series rectifies this issue by charging the memcg when the
> hugetlb folio is allocated, and uncharging when the folio is freed. In
> addition, a new selftest is added to demonstrate and verify this new
> behavior.
>
> Nhat Pham (2):
> hugetlb: memcg: account hugetlb-backed memory in memory controller
> selftests: add a selftest to verify hugetlb usage in memcg
>
> MAINTAINERS | 2 +
> fs/hugetlbfs/inode.c | 2 +-
> include/linux/hugetlb.h | 6 +-
> include/linux/memcontrol.h | 8 +
> mm/hugetlb.c | 23 +-
> mm/memcontrol.c | 40 ++++
> tools/testing/selftests/cgroup/.gitignore | 1 +
> tools/testing/selftests/cgroup/Makefile | 2 +
> .../selftests/cgroup/test_hugetlb_memcg.c | 222 ++++++++++++++++++
> 9 files changed, 297 insertions(+), 9 deletions(-)
> create mode 100644 tools/testing/selftests/cgroup/test_hugetlb_memcg.c
>
> --
> 2.34.1
>
We've had this behavior at Google for a long time, and we're actually
getting rid of it. hugetlb pages are a precious resource that should
be accounted for separately. They are not just any memory, they are
physically contiguous memory, charging them the same as any other
region of the same size ended up not making sense, especially not for
larger hugetlb page sizes.
Additionally, if this behavior is changed just like that, there will
be quite a few workloads that will break badly because they'll hit
their limits immediately - imagine a container that uses 1G hugetlb
pages to back something large (a database, a VM), and 'plain' memory
for control processes.
What do your workloads do? Is it not possible for you to account for
hugetlb pages separately? Sure, it can be annoying to have to deal
with 2 separate totals that you need to take into account, but again,
hugetlb pages are a resource that is best dealt with separately.
- Frank
next prev parent reply other threads:[~2023-09-26 20:50 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-26 19:49 Nhat Pham
2023-09-26 19:49 ` [PATCH 1/2] hugetlb: memcg: account hugetlb-backed memory in memory controller Nhat Pham
2023-09-26 20:50 ` Frank van der Linden [this message]
2023-09-26 22:14 ` [PATCH 0/2] hugetlb memcg accounting Johannes Weiner
2023-09-27 12:50 ` Michal Hocko
2023-09-27 16:44 ` Johannes Weiner
2023-09-27 17:22 ` Nhat Pham
2023-09-26 23:31 ` Nhat Pham
2023-09-27 11:21 ` Michal Hocko
2023-09-27 18:47 ` Johannes Weiner
2023-09-27 21:37 ` Roman Gushchin
2023-09-28 12:52 ` Johannes Weiner
2023-10-01 23:27 ` Mike Kravetz
2023-10-02 14:42 ` Johannes Weiner
2023-10-02 14:58 ` Michal Hocko
2023-10-02 15:36 ` Johannes Weiner
2023-09-27 23:33 ` Nhat Pham
2023-09-28 1:00 ` Nhat Pham
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=CAPTztWY8eDSa1qKx35hTm5ef+e13SDnRHDrevc-1V1v7-pEP3w@mail.gmail.com \
--to=fvdl@google.com \
--cc=akpm@linux-foundation.org \
--cc=cgroups@vger.kernel.org \
--cc=hannes@cmpxchg.org \
--cc=kernel-team@meta.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lizefan.x@bytedance.com \
--cc=mhocko@kernel.org \
--cc=mike.kravetz@oracle.com \
--cc=muchun.song@linux.dev \
--cc=nphamcs@gmail.com \
--cc=riel@surriel.com \
--cc=roman.gushchin@linux.dev \
--cc=shakeelb@google.com \
--cc=shuah@kernel.org \
--cc=tj@kernel.org \
--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