linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Nhat Pham <nphamcs@gmail.com>
To: Yosry Ahmed <yosryahmed@google.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, linux-mm@kvack.org,
	 kernel-team@meta.com, linux-kernel@vger.kernel.org,
	cgroups@vger.kernel.org
Subject: Re: [PATCH v2 1/2] hugetlb: memcg: account hugetlb-backed memory in memory controller
Date: Thu, 28 Sep 2023 18:07:36 -0700	[thread overview]
Message-ID: <CAKEwX=Npb4mwZ2ibJkmD5GyqXazr7PH8UGLu+YSDY8acf152Eg@mail.gmail.com> (raw)
In-Reply-To: <CAKEwX=M=8KYqvBTz9z1csrsFUpGf2tgWj-oyu96dSpRjn3ZnUQ@mail.gmail.com>

On Thu, Sep 28, 2023 at 5:58 PM Nhat Pham <nphamcs@gmail.com> wrote:
>
> On Thu, Sep 28, 2023 at 5:38 PM Yosry Ahmed <yosryahmed@google.com> wrote:
> >
> > <snip>
> >
> > >
> > > +
> > > +/**
> > > + * mem_cgroup_hugetlb_charge_folio - Charge a newly allocated hugetlb folio.
> > > + * @folio: folio to charge.
> > > + * @gfp: reclaim mode
> > > + *
> > > + * This function charges an allocated hugetlbf folio to the memcg of the
> > > + * current task.
> > > + *
> > > + * Returns 0 on success. Otherwise, an error code is returned.
> > > + */
> > > +int mem_cgroup_hugetlb_charge_folio(struct folio *folio, gfp_t gfp)
> > > +{
> > > +       struct mem_cgroup *memcg;
> > > +       int ret;
> > > +
> > > +       if (mem_cgroup_disabled() ||
> > > +               !(cgrp_dfl_root.flags & CGRP_ROOT_MEMORY_HUGETLB_ACCOUNTING))
> >
> > What happens if the memory controller is mounted in a cgroup v1
> > hierarchy? It appears to me that we *will* go through with hugetlb
> > charging in this case?
>
> Ah right, cgroup v1. Does it not work with mount flag guarding?
> What's the behavior of cgroup v1 when it comes to memory
> recursive protection for e.g (which this mount flag is based on)?
>
> If it doesn't work, we'll have to add a separate knob for v1 -
> no biggies.

But to be clear, my intention is that we're not adding this
feature to v1 (which, to my understanding, has been
deprecated).

If it's added by virtue of it sharing infrastructure with v2,
then it's fine, but only if the mount option still works to
guard against unintentional enablement (if not we'll
also short-circuit v1, or add knobs if ppl really want
it in v1 as well).

If it's not added at all, then I don't have any complaints :)

>
> Other than this concern, I don't have anything against cgroup v1
> having this feature per se - everything should still work. But let
> I know if it can break cgroupv1 accounting otherwise :)
>
> >
> > >
> > > +               return 0;
> > > +
> > > +       memcg = get_mem_cgroup_from_current();
> > > +       ret = charge_memcg(folio, memcg, gfp);
> > > +       mem_cgroup_put(memcg);
> > > +
> > > +       return ret;
> > > +}
> > > +
> > >  /**
> > >   * mem_cgroup_swapin_charge_folio - Charge a newly allocated folio for swapin.
> > >   * @folio: folio to charge.
> > > --
> > > 2.34.1


  reply	other threads:[~2023-09-29  1:07 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-28  0:57 [PATCH v2 0/2] hugetlb memcg accounting Nhat Pham
2023-09-28  0:57 ` [PATCH v2 1/2] hugetlb: memcg: account hugetlb-backed memory in memory controller Nhat Pham
2023-09-28 22:59   ` Frank van der Linden
2023-09-29  0:33     ` Nhat Pham
2023-09-29  0:38   ` Yosry Ahmed
2023-09-29  0:58     ` Nhat Pham
2023-09-29  1:07       ` Nhat Pham [this message]
2023-09-29  1:18         ` Yosry Ahmed
2023-09-29  1:25           ` Nhat Pham
2023-09-29 15:08           ` Johannes Weiner
2023-09-29 15:11             ` Yosry Ahmed
2023-09-29 17:42               ` Johannes Weiner
2023-09-29 17:48                 ` Nhat Pham
2023-09-29 18:07                 ` Frank van der Linden
2023-10-02 12:18                 ` Michal Hocko
2023-09-29 18:17   ` [PATCH v2 1/2] hugetlb: memcg: account hugetlb-backed memory in memory controller (fix) Nhat Pham
2023-09-29 18:19     ` Nhat Pham
2023-10-02 13:43   ` [PATCH v2 1/2] hugetlb: memcg: account hugetlb-backed memory in memory controller Michal Hocko
2023-10-02 14:50     ` Johannes Weiner
2023-10-02 15:08       ` Michal Hocko
2023-10-02 15:25         ` Johannes Weiner
2023-10-02 17:32           ` Nhat Pham
2023-10-03  9:17           ` Michal Hocko
2023-10-02 16:21     ` Johannes Weiner
2023-10-02 17:28     ` Nhat Pham
2023-09-28  0:57 ` [PATCH v2 2/2] selftests: add a selftest to verify hugetlb usage in memcg 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='CAKEwX=Npb4mwZ2ibJkmD5GyqXazr7PH8UGLu+YSDY8acf152Eg@mail.gmail.com' \
    --to=nphamcs@gmail.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=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