From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
To: Shakeel Butt <shakeelb@google.com>
Cc: Cgroups <cgroups@vger.kernel.org>,
"Linux MM" <linux-mm@kvack.org>,
"Andrew Morton" <akpm@linux-foundation.org>,
"Johannes Weiner" <hannes@cmpxchg.org>,
"Michal Hocko" <mhocko@kernel.org>,
"Michal Koutný" <mkoutny@suse.com>,
"Peter Zijlstra" <peterz@infradead.org>,
"Thomas Gleixner" <tglx@linutronix.de>,
"Vladimir Davydov" <vdavydov.dev@gmail.com>,
"Waiman Long" <longman@redhat.com>,
"Roman Gushchin" <guro@fb.com>
Subject: Re: [PATCH v3 3/5] mm/memcg: Protect per-CPU counter by disabling preemption on PREEMPT_RT where needed.
Date: Mon, 21 Feb 2022 12:31:17 +0100 [thread overview]
Message-ID: <YhN4BSQ1RLomLoyl@linutronix.de> (raw)
In-Reply-To: <CALvZod4eZWVfibhxu0P0ZQ35cB=vDbde=VNeXiBZfED=k3YPOQ@mail.gmail.com>
On 2022-02-18 09:25:29 [-0800], Shakeel Butt wrote:
> > diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> > index 0b5117ed2ae08..36ab3660f2c6d 100644
> > --- a/mm/memcontrol.c
> > +++ b/mm/memcontrol.c
> > @@ -630,6 +630,28 @@ static DEFINE_SPINLOCK(stats_flush_lock);
> > static DEFINE_PER_CPU(unsigned int, stats_updates);
> > static atomic_t stats_flush_threshold = ATOMIC_INIT(0);
> >
> > +/*
> > + * Accessors to ensure that preemption is disabled on PREEMPT_RT because it can
> > + * not rely on this as part of an acquired spinlock_t lock. These functions are
> > + * never used in hardirq context on PREEMPT_RT and therefore disabling preemtion
> > + * is sufficient.
> > + */
> > +static void memcg_stats_lock(void)
> > +{
> > +#ifdef CONFIG_PREEMPT_RT
> > + preempt_disable();
> > +#else
> > + VM_BUG_ON(!irqs_disabled());
> > +#endif
> > +}
> > +
> > +static void memcg_stats_unlock(void)
> > +{
> > +#ifdef CONFIG_PREEMPT_RT
> > + preempt_enable();
> > +#endif
> > +}
> > +
> > static inline void memcg_rstat_updated(struct mem_cgroup *memcg, int val)
> > {
> > unsigned int x;
> > @@ -706,6 +728,7 @@ void __mod_memcg_lruvec_state(struct lruvec *lruvec, enum node_stat_item idx,
> > pn = container_of(lruvec, struct mem_cgroup_per_node, lruvec);
> > memcg = pn->memcg;)
> >
> > + memcg_stats_lock();
>
> The call chains from rmap.c have not really disabled irqs. Actually
> there is a comment in do_page_add_anon_rmap() "We use the irq-unsafe
> __{inc|mod}_zone_page_stat because these counters are not modified in
> interrupt context, and pte lock(a spinlock) is held, which implies
> preemption disabled".
>
> VM_BUG_ON(!irqs_disabled()) within memcg_stats_lock() would be giving
> false error reports for CONFIG_PREEMPT_NONE kernels.
So three caller, including do_page_add_anon_rmap():
__mod_lruvec_page_state() -> __mod_lruvec_state() -> __mod_memcg_lruvec_state()
is affected. Here we get false warnings because interrupts may not be
disabled and it is intended. Hmmm.
The odd part is that this only affects certain idx so any kind of
additional debugging would need to take this into account.
What about memcg_rstat_updated()? It does:
| x = __this_cpu_add_return(stats_updates, abs(val));
| if (x > MEMCG_CHARGE_BATCH) {
| atomic_add(x / MEMCG_CHARGE_BATCH, &stats_flush_threshold);
| __this_cpu_write(stats_updates, 0);
| }
The writes to stats_updates can happen from IRQ-context and with
disabled preemption only. So this is not good, right?
Sebastian
next prev parent reply other threads:[~2022-02-21 11:31 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-17 9:47 [PATCH v3 0/5] mm/memcg: Address PREEMPT_RT problems instead of disabling it Sebastian Andrzej Siewior
2022-02-17 9:47 ` [PATCH v3 1/5] mm/memcg: Revert ("mm/memcg: optimize user context object stock access") Sebastian Andrzej Siewior
2022-02-18 16:09 ` Shakeel Butt
2022-02-21 14:26 ` Michal Hocko
2022-02-17 9:47 ` [PATCH v3 2/5] mm/memcg: Disable threshold event handlers on PREEMPT_RT Sebastian Andrzej Siewior
2022-02-18 16:39 ` Shakeel Butt
2022-02-21 14:27 ` Michal Hocko
2022-02-17 9:48 ` [PATCH v3 3/5] mm/memcg: Protect per-CPU counter by disabling preemption on PREEMPT_RT where needed Sebastian Andrzej Siewior
2022-02-18 17:25 ` Shakeel Butt
2022-02-21 11:31 ` Sebastian Andrzej Siewior [this message]
2022-02-21 12:12 ` Sebastian Andrzej Siewior
2022-02-21 13:18 ` Michal Koutný
2022-02-21 13:58 ` Sebastian Andrzej Siewior
2022-02-17 9:48 ` [PATCH v3 4/5] mm/memcg: Opencode the inner part of obj_cgroup_uncharge_pages() in drain_obj_stock() Sebastian Andrzej Siewior
2022-02-18 18:40 ` Shakeel Butt
2022-02-18 19:07 ` Roman Gushchin
2022-02-21 14:30 ` Michal Hocko
2022-02-17 9:48 ` [PATCH v3 5/5] mm/memcg: Protect memcg_stock with a local_lock_t Sebastian Andrzej Siewior
2022-02-21 14:46 ` Michal Hocko
2022-02-21 15:19 ` Sebastian Andrzej Siewior
2022-02-21 16:24 ` Michal Hocko
2022-02-21 16:44 ` Sebastian Andrzej Siewior
2022-02-21 17:17 ` Michal Hocko
2022-02-21 17:25 ` Sebastian Andrzej Siewior
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=YhN4BSQ1RLomLoyl@linutronix.de \
--to=bigeasy@linutronix.de \
--cc=akpm@linux-foundation.org \
--cc=cgroups@vger.kernel.org \
--cc=guro@fb.com \
--cc=hannes@cmpxchg.org \
--cc=linux-mm@kvack.org \
--cc=longman@redhat.com \
--cc=mhocko@kernel.org \
--cc=mkoutny@suse.com \
--cc=peterz@infradead.org \
--cc=shakeelb@google.com \
--cc=tglx@linutronix.de \
--cc=vdavydov.dev@gmail.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