From: Andrew Morton <akpm@linux-foundation.org>
To: mm-commits@vger.kernel.org, vbabka@suse.cz, shakeelb@google.com,
rientjes@google.com, muchun.song@linux.dev, mhocko@kernel.org,
hannes@cmpxchg.org, dennis@kernel.org, roman.gushchin@linux.dev,
akpm@linux-foundation.org
Subject: + mm-kmem-add-direct-objcg-pointer-to-task_struct.patch added to mm-unstable branch
Date: Fri, 29 Sep 2023 11:42:48 -0700 [thread overview]
Message-ID: <20230929184249.8F34FC433C8@smtp.kernel.org> (raw)
The patch titled
Subject: mm: kmem: add direct objcg pointer to task_struct
has been added to the -mm mm-unstable branch. Its filename is
mm-kmem-add-direct-objcg-pointer-to-task_struct.patch
This patch will shortly appear at
https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/mm-kmem-add-direct-objcg-pointer-to-task_struct.patch
This patch will later appear in the mm-unstable branch at
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next via the mm-everything
branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
and is updated there every 2-3 working days
------------------------------------------------------
From: Roman Gushchin <roman.gushchin@linux.dev>
Subject: mm: kmem: add direct objcg pointer to task_struct
Date: Fri, 29 Sep 2023 11:00:52 -0700
To charge a freshly allocated kernel object to a memory cgroup, the kernel
needs to obtain an objcg pointer. Currently it does it indirectly by
obtaining the memcg pointer first and then calling to
__get_obj_cgroup_from_memcg().
Usually tasks spend their entire life belonging to the same object cgroup.
So it makes sense to save the objcg pointer on task_struct directly, so
it can be obtained faster. It requires some work on fork, exit and cgroup
migrate paths, but these paths are way colder.
To avoid any costly synchronization the following rules are applied:
1) A task sets it's objcg pointer itself.
2) If a task is being migrated to another cgroup, the least
significant bit of the objcg pointer is set atomically.
3) On the allocation path the objcg pointer is obtained locklessly
using the READ_ONCE() macro and the least significant bit is
checked. If it's set, the following procedure is used to update
it locklessly:
- task->objcg is zeroed using cmpxcg
- new objcg pointer is obtained
- task->objcg is updated using try_cmpxchg
- operation is repeated if try_cmpxcg fails
It guarantees that no updates will be lost if task migration
is racing against objcg pointer update. It also allows to keep
both read and write paths fully lockless.
Because the task is keeping a reference to the objcg, it can't go away
while the task is alive.
This commit doesn't change the way the remote memcg charging works.
Link: https://lkml.kernel.org/r/20230929180056.1122002-3-roman.gushchin@linux.dev
Signed-off-by: Roman Gushchin (Cruise) <roman.gushchin@linux.dev>
Cc: David Rientjes <rientjes@google.com>
Cc: Dennis Zhou <dennis@kernel.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Muchun Song <muchun.song@linux.dev>
Cc: Shakeel Butt <shakeelb@google.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
include/linux/memcontrol.h | 10 +++
include/linux/sched.h | 4 +
mm/memcontrol.c | 111 ++++++++++++++++++++++++++++++++---
3 files changed, 116 insertions(+), 9 deletions(-)
--- a/include/linux/memcontrol.h~mm-kmem-add-direct-objcg-pointer-to-task_struct
+++ a/include/linux/memcontrol.h
@@ -544,6 +544,16 @@ static inline bool folio_memcg_kmem(stru
return folio->memcg_data & MEMCG_DATA_KMEM;
}
+static inline bool current_objcg_needs_update(struct obj_cgroup *objcg)
+{
+ return (struct obj_cgroup *)((unsigned long)objcg & 0x1);
+}
+
+static inline struct obj_cgroup *
+current_objcg_without_update_flag(struct obj_cgroup *objcg)
+{
+ return (struct obj_cgroup *)((unsigned long)objcg & ~0x1);
+}
#else
static inline bool folio_memcg_kmem(struct folio *folio)
--- a/include/linux/sched.h~mm-kmem-add-direct-objcg-pointer-to-task_struct
+++ a/include/linux/sched.h
@@ -1443,6 +1443,10 @@ struct task_struct {
struct mem_cgroup *active_memcg;
#endif
+#ifdef CONFIG_MEMCG_KMEM
+ struct obj_cgroup *objcg;
+#endif
+
#ifdef CONFIG_BLK_CGROUP
struct gendisk *throttle_disk;
#endif
--- a/mm/memcontrol.c~mm-kmem-add-direct-objcg-pointer-to-task_struct
+++ a/mm/memcontrol.c
@@ -3041,6 +3041,47 @@ static struct obj_cgroup *__get_obj_cgro
return objcg;
}
+static struct obj_cgroup *current_objcg_update(struct obj_cgroup *old)
+{
+ struct mem_cgroup *memcg;
+ struct obj_cgroup *objcg = NULL, *tmp = old;
+
+ old = current_objcg_without_update_flag(old);
+ if (old)
+ obj_cgroup_put(old);
+
+ rcu_read_lock();
+ do {
+ /* Atomically drop the update bit, */
+ WARN_ON_ONCE(cmpxchg(¤t->objcg, tmp, 0) != tmp);
+
+ /* ...obtain the new objcg pointer */
+ 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;
+ }
+
+ /*
+ * ...and try atomically set up a new objcg pointer. If it
+ * fails, it means the update flag was set concurrently, so
+ * the whole procedure should be repeated.
+ */
+ tmp = 0;
+ } while (!try_cmpxchg(¤t->objcg, &tmp, objcg));
+ rcu_read_unlock();
+
+ return objcg;
+}
+
+static inline void current_objcg_set_needs_update(struct task_struct *task)
+{
+ /* atomically set the update bit */
+ set_bit(0, (unsigned long *)¤t->objcg);
+}
+
__always_inline struct obj_cgroup *get_obj_cgroup_from_current(void)
{
struct mem_cgroup *memcg;
@@ -3048,19 +3089,26 @@ __always_inline struct obj_cgroup *get_o
if (in_task()) {
memcg = current->active_memcg;
+ if (unlikely(memcg))
+ goto from_memcg;
- /* Memcg to charge can't be determined. */
- if (likely(!memcg) && (!current->mm || (current->flags & PF_KTHREAD)))
- return NULL;
+ objcg = READ_ONCE(current->objcg);
+ if (unlikely(current_objcg_needs_update(objcg)))
+ objcg = current_objcg_update(objcg);
+
+ if (objcg) {
+ obj_cgroup_get(objcg);
+ return objcg;
+ }
} else {
memcg = this_cpu_read(int_active_memcg);
- if (likely(!memcg))
- return NULL;
+ if (unlikely(memcg))
+ goto from_memcg;
}
+ return NULL;
+from_memcg:
rcu_read_lock();
- if (!memcg)
- memcg = mem_cgroup_from_task(current);
objcg = __get_obj_cgroup_from_memcg(memcg);
rcu_read_unlock();
return objcg;
@@ -6400,6 +6448,7 @@ static void mem_cgroup_move_task(void)
mem_cgroup_clear_mc();
}
}
+
#else /* !CONFIG_MMU */
static int mem_cgroup_can_attach(struct cgroup_taskset *tset)
{
@@ -6413,8 +6462,27 @@ static void mem_cgroup_move_task(void)
}
#endif
+#ifdef CONFIG_MEMCG_KMEM
+static void mem_cgroup_fork(struct task_struct *task)
+{
+ /*
+ * Set the update flag to cause task->objcg to be initialized lazily
+ * on the first allocation.
+ */
+ task->objcg = (struct obj_cgroup *)0x1;
+}
+
+static void mem_cgroup_exit(struct task_struct *task)
+{
+ struct obj_cgroup *objcg = current_objcg_without_update_flag(task->objcg);
+
+ if (objcg)
+ obj_cgroup_put(objcg);
+}
+#endif
+
#ifdef CONFIG_LRU_GEN
-static void mem_cgroup_attach(struct cgroup_taskset *tset)
+static void mem_cgroup_lru_gen_attach(struct cgroup_taskset *tset)
{
struct task_struct *task;
struct cgroup_subsys_state *css;
@@ -6432,10 +6500,29 @@ static void mem_cgroup_attach(struct cgr
task_unlock(task);
}
#else
+static void mem_cgroup_lru_gen_attach(struct cgroup_taskset *tset) {}
+#endif /* CONFIG_LRU_GEN */
+
+#ifdef CONFIG_MEMCG_KMEM
+static void mem_cgroup_kmem_attach(struct cgroup_taskset *tset)
+{
+ struct task_struct *task;
+ struct cgroup_subsys_state *css;
+
+ cgroup_taskset_for_each(task, css, tset)
+ current_objcg_set_needs_update(task);
+}
+#else
+static void mem_cgroup_kmem_attach(struct cgroup_taskset *tset) {}
+#endif /* CONFIG_MEMCG_KMEM */
+
+#if defined(CONFIG_LRU_GEN) || defined(CONFIG_MEMCG_KMEM)
static void mem_cgroup_attach(struct cgroup_taskset *tset)
{
+ mem_cgroup_lru_gen_attach(tset);
+ mem_cgroup_kmem_attach(tset);
}
-#endif /* CONFIG_LRU_GEN */
+#endif
static int seq_puts_memcg_tunable(struct seq_file *m, unsigned long value)
{
@@ -6845,9 +6932,15 @@ struct cgroup_subsys memory_cgrp_subsys
.css_reset = mem_cgroup_css_reset,
.css_rstat_flush = mem_cgroup_css_rstat_flush,
.can_attach = mem_cgroup_can_attach,
+#if defined(CONFIG_LRU_GEN) || defined(CONFIG_MEMCG_KMEM)
.attach = mem_cgroup_attach,
+#endif
.cancel_attach = mem_cgroup_cancel_attach,
.post_attach = mem_cgroup_move_task,
+#ifdef CONFIG_MEMCG_KMEM
+ .fork = mem_cgroup_fork,
+ .exit = mem_cgroup_exit,
+#endif
.dfl_cftypes = memory_files,
.legacy_cftypes = mem_cgroup_legacy_files,
.early_init = 0,
_
Patches currently in -mm which might be from roman.gushchin@linux.dev are
mm-kmem-optimize-get_obj_cgroup_from_current.patch
mm-kmem-add-direct-objcg-pointer-to-task_struct.patch
mm-kmem-make-memcg-keep-a-reference-to-the-original-objcg.patch
mm-kmem-scoped-objcg-protection.patch
percpu-scoped-objcg-protection.patch
next reply other threads:[~2023-09-29 18:42 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-29 18:42 Andrew Morton [this message]
2023-10-01 16:42 ` + mm-kmem-add-direct-objcg-pointer-to-task_struct.patch added to mm-unstable branch Roman Gushchin
-- strict thread matches above, loose matches on Subject: below --
2023-10-10 18:20 Andrew Morton
2023-10-10 22:15 ` Roman Gushchin
2023-10-10 23:02 ` Andrew Morton
2023-10-16 22:58 Andrew Morton
2023-10-18 18:08 ` Roman Gushchin
2023-10-19 7:14 ` Vlastimil Babka
2023-10-20 17:11 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=20230929184249.8F34FC433C8@smtp.kernel.org \
--to=akpm@linux-foundation.org \
--cc=dennis@kernel.org \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mhocko@kernel.org \
--cc=mm-commits@vger.kernel.org \
--cc=muchun.song@linux.dev \
--cc=rientjes@google.com \
--cc=roman.gushchin@linux.dev \
--cc=shakeelb@google.com \
--cc=vbabka@suse.cz \
/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.