From: Roman Gushchin <roman.gushchin@linux.dev>
To: Yosry Ahmed <yosryahmed@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Johannes Weiner <hannes@cmpxchg.org>,
Michal Hocko <mhocko@kernel.org>,
Shakeel Butt <shakeel.butt@linux.dev>,
Muchun Song <muchun.song@linux.dev>
Subject: Re: [PATCH v2 1/5] mm: memcg: don't call propagate_protected_usage() needlessly
Date: Wed, 24 Jul 2024 23:31:58 +0000 [thread overview]
Message-ID: <ZqGO7jtUCM2tG_QZ@google.com> (raw)
In-Reply-To: <CAJD7tkYOgYMKp+u97wm6biA+C_2BR-B2hy6zi=cVqHovUxLTRA@mail.gmail.com>
On Wed, Jul 24, 2024 at 04:13:17PM -0700, Yosry Ahmed wrote:
> On Wed, Jul 24, 2024 at 1:21 PM Roman Gushchin <roman.gushchin@linux.dev> wrote:
> >
> > Memory protection (min/low) requires a constant tracking of
> > protected memory usage. propagate_protected_usage() is called
> > on each page counters update and does a number of operations
> > even in cases when the actual memory protection functionality
> > is not supported (e.g. hugetlb cgroups or memcg swap counters).
> >
> > It's obviously inefficient and leads to a waste of CPU cycles.
> > It can be addressed by calling propagate_protected_usage() only
> > for the counters which do support memory guarantees. As of now
> > it's only memcg->memory - the unified memory memcg counter.
> >
> > Signed-off-by: Roman Gushchin <roman.gushchin@linux.dev>
> > ---
> > include/linux/page_counter.h | 8 +++++++-
> > mm/hugetlb_cgroup.c | 4 ++--
> > mm/memcontrol.c | 16 ++++++++--------
> > mm/page_counter.c | 16 +++++++++++++---
> > 4 files changed, 30 insertions(+), 14 deletions(-)
> >
> > diff --git a/include/linux/page_counter.h b/include/linux/page_counter.h
> > index 860f313182e7..b31fd5b208aa 100644
> > --- a/include/linux/page_counter.h
> > +++ b/include/linux/page_counter.h
> > @@ -32,6 +32,7 @@ struct page_counter {
> > /* Keep all the read most fields in a separete cacheline. */
> > CACHELINE_PADDING(_pad2_);
> >
> > + bool protection_support;
> > unsigned long min;
> > unsigned long low;
> > unsigned long high;
> > @@ -45,12 +46,17 @@ struct page_counter {
> > #define PAGE_COUNTER_MAX (LONG_MAX / PAGE_SIZE)
> > #endif
> >
> > +/*
> > + * Protection is supported only for the first counter (with id 0).
> > + */
> > static inline void page_counter_init(struct page_counter *counter,
> > - struct page_counter *parent)
> > + struct page_counter *parent,
> > + bool protection_support)
>
> Would it be better to make this an internal helper (e.g.
> __page_counter_init()), and add another API function that passes in
> protection_support=true, for example:
>
> static inline void page_counter_init_protected(..)
> {
> __page_counter_init(.., true);
> }
>
> This will get rid of the naked booleans at the callsites of
> page_counter_init(), which are more difficult to interpret. It will
> also reduce the diff as we only need to change the page_counter_init()
> calls of memcg->memory.
>
> WDYT?
No strong opinion here. There are basically 2 call sites and I don't expect
this number to grow, so not sure if it makes sense to add 2 new helpers.
Another option I thought about is to leave page_counter_init() as it is
and add a separate function to enable the protection tracking.
Thanks!
next prev parent reply other threads:[~2024-07-24 23:32 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-24 20:20 [PATCH v2 0/5] This patchset reorganizes page_counter structures which helps to make Roman Gushchin
2024-07-24 20:20 ` [PATCH v2 1/5] mm: memcg: don't call propagate_protected_usage() needlessly Roman Gushchin
2024-07-24 20:52 ` Shakeel Butt
2024-07-24 23:13 ` Yosry Ahmed
2024-07-24 23:31 ` Roman Gushchin [this message]
2024-07-24 23:35 ` Yosry Ahmed
2024-07-24 20:21 ` [PATCH v2 2/5] mm: page_counters: put page_counter_calculate_protection() under CONFIG_MEMCG Roman Gushchin
2024-07-24 23:05 ` Shakeel Butt
2024-07-24 20:21 ` [PATCH v2 3/5] mm: memcg: merge multiple page_counters into a single structure Roman Gushchin
2024-07-24 23:43 ` Shakeel Butt
2024-07-25 21:42 ` Johannes Weiner
2024-07-25 23:33 ` Roman Gushchin
2024-07-26 23:31 ` Johannes Weiner
2024-07-24 20:21 ` [PATCH v2 4/5] mm: page_counters: initialize usage using ATOMIC_LONG_INIT() macro Roman Gushchin
2024-07-24 23:45 ` Shakeel Butt
2024-07-24 20:21 ` [PATCH v2 5/5] mm: memcg: convert enum res_type to mem_counter_type Roman Gushchin
2024-07-24 23:48 ` Shakeel Butt
2024-07-24 23:54 ` Roman Gushchin
2024-07-24 20:40 ` [PATCH v2 0/5] This patchset reorganizes page_counter structures which helps to make Roman Gushchin
2024-07-24 22:17 ` Shakeel Butt
2024-07-24 22:30 ` Roman Gushchin
2024-07-25 21:42 ` Andrew Morton
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=ZqGO7jtUCM2tG_QZ@google.com \
--to=roman.gushchin@linux.dev \
--cc=akpm@linux-foundation.org \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=muchun.song@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 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.