From: Roman Gushchin <roman.gushchin@linux.dev>
To: Johannes Weiner <hannes@cmpxchg.org>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
cgroups@vger.kernel.org, Michal Hocko <mhocko@kernel.org>,
Shakeel Butt <shakeelb@google.com>,
Muchun Song <muchun.song@linux.dev>,
Dennis Zhou <dennis@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH rfc 2/5] mm: kmem: add direct objcg pointer to task_struct
Date: Mon, 2 Oct 2023 15:03:48 -0700 [thread overview]
Message-ID: <ZRs-RKsOhtO3eclx@P9FQF9L96D> (raw)
In-Reply-To: <20231002201254.GA8435@cmpxchg.org>
On Mon, Oct 02, 2023 at 04:12:54PM -0400, Johannes Weiner wrote:
> On Wed, Sep 27, 2023 at 08:08:29AM -0700, Roman Gushchin wrote:
> > @@ -3001,6 +3001,47 @@ static struct obj_cgroup *__get_obj_cgroup_from_memcg(struct mem_cgroup *memcg)
> > return objcg;
> > }
> >
> > +static DEFINE_SPINLOCK(current_objcg_lock);
> > +
> > +static struct obj_cgroup *current_objcg_update(struct obj_cgroup *old)
> > +{
> > + struct mem_cgroup *memcg;
> > + struct obj_cgroup *objcg;
> > + unsigned long flags;
> > +
> > + old = current_objcg_clear_update_flag(old);
> > + if (old)
> > + obj_cgroup_put(old);
> > +
> > + spin_lock_irqsave(¤t_objcg_lock, flags);
> > + rcu_read_lock();
> > + memcg = mem_cgroup_from_task(current);
> > + for (; memcg != root_mem_cgroup; memcg = parent_mem_cgroup(memcg)) {
> > + objcg = rcu_dereference(memcg->objcg);
> > + if (objcg && obj_cgroup_tryget(objcg))
> > + break;
> > + objcg = NULL;
> > + }
> > + rcu_read_unlock();
>
> Can this tryget() actually fail when this is called on the current
> task during fork() and attach()? A cgroup cannot be offlined while
> there is a task in it.
Highly theoretically it can if it races against a migration of the current
task to another memcg and the previous memcg is getting offlined.
I actually might make sense to apply the same approach for memcgs as well
(saving a lazily-updating memcg pointer on task_struct). Then it will be
possible to ditch this "for" loop. But I need some time to master the code
and run benchmarks. Idk if it will make enough difference to justify the change.
Btw, this is the rfc version, while there is a newer v1 version, which Andrew
already picked for mm-unstable. Both of your comments still apply, just fyi.
>
> > @@ -6345,6 +6393,22 @@ static void mem_cgroup_move_task(void)
> > mem_cgroup_clear_mc();
> > }
> > }
> > +
> > +#ifdef CONFIG_MEMCG_KMEM
> > +static void mem_cgroup_fork(struct task_struct *task)
> > +{
> > + task->objcg = (struct obj_cgroup *)0x1;
>
> dup_task_struct() will copy this pointer from the old task. Would it
> be possible to bump the refcount here instead? That would save quite a
> bit of work during fork().
Yeah, it should be possible. It won't save a lot, but I agree it makes
sense. I'll take a look and will prepare a separate patch for this.
Thank you!
next prev parent reply other threads:[~2023-10-02 22:04 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-27 15:08 [PATCH rfc 0/5] mm: improve performance of kernel memory accounting Roman Gushchin
2023-09-27 15:08 ` [PATCH rfc 1/5] mm: kmem: optimize get_obj_cgroup_from_current() Roman Gushchin
2023-09-27 15:08 ` [PATCH rfc 2/5] mm: kmem: add direct objcg pointer to task_struct Roman Gushchin
2023-10-02 20:12 ` Johannes Weiner
2023-10-02 22:03 ` Roman Gushchin [this message]
2023-10-03 14:22 ` Johannes Weiner
2023-10-03 16:06 ` Roman Gushchin
2023-09-27 15:08 ` [PATCH rfc 3/5] mm: kmem: make memcg keep a reference to the original objcg Roman Gushchin
2023-09-27 15:08 ` [PATCH rfc 4/5] mm: kmem: scoped objcg protection Roman Gushchin
2023-09-27 15:08 ` [PATCH rfc 5/5] percpu: " Roman Gushchin
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=ZRs-RKsOhtO3eclx@P9FQF9L96D \
--to=roman.gushchin@linux.dev \
--cc=akpm@linux-foundation.org \
--cc=cgroups@vger.kernel.org \
--cc=dennis@kernel.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=shakeelb@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;
as well as URLs for NNTP newsgroup(s).