* [PATCH v4] memcg: Don't wait writeback completion when release memcg.
@ 2025-08-27 20:45 Julian Sun
2025-08-27 21:25 ` Tejun Heo
0 siblings, 1 reply; 2+ messages in thread
From: Julian Sun @ 2025-08-27 20:45 UTC (permalink / raw)
To: cgroups, linux-mm; +Cc: jack, tj, muchun.song
Recently, we encountered the following hung task:
INFO: task kworker/4:1:1334558 blocked for more than 1720 seconds.
[Wed Jul 30 17:47:45 2025] Workqueue: cgroup_destroy css_free_rwork_fn
[Wed Jul 30 17:47:45 2025] Call Trace:
[Wed Jul 30 17:47:45 2025] __schedule+0x934/0xe10
[Wed Jul 30 17:47:45 2025] ? complete+0x3b/0x50
[Wed Jul 30 17:47:45 2025] ? _cond_resched+0x15/0x30
[Wed Jul 30 17:47:45 2025] schedule+0x40/0xb0
[Wed Jul 30 17:47:45 2025] wb_wait_for_completion+0x52/0x80
[Wed Jul 30 17:47:45 2025] ? finish_wait+0x80/0x80
[Wed Jul 30 17:47:45 2025] mem_cgroup_css_free+0x22/0x1b0
[Wed Jul 30 17:47:45 2025] css_free_rwork_fn+0x42/0x380
[Wed Jul 30 17:47:45 2025] process_one_work+0x1a2/0x360
[Wed Jul 30 17:47:45 2025] worker_thread+0x30/0x390
[Wed Jul 30 17:47:45 2025] ? create_worker+0x1a0/0x1a0
[Wed Jul 30 17:47:45 2025] kthread+0x110/0x130
[Wed Jul 30 17:47:45 2025] ? __kthread_cancel_work+0x40/0x40
[Wed Jul 30 17:47:45 2025] ret_from_fork+0x1f/0x30
The direct cause is that memcg spends a long time waiting for dirty page
writeback of foreign memcgs during release.
The root causes are:
a. The wb may have multiple writeback tasks, containing millions
of dirty pages, as shown below:
>>> for work in list_for_each_entry("struct wb_writeback_work", \
wb.work_list.address_of_(), "list"):
... print(work.nr_pages, work.reason, hex(work))
...
900628 WB_REASON_FOREIGN_FLUSH 0xffff969e8d956b40
1116521 WB_REASON_FOREIGN_FLUSH 0xffff9698332a9540
1275228 WB_REASON_FOREIGN_FLUSH 0xffff969d9b444bc0
1099673 WB_REASON_FOREIGN_FLUSH 0xffff969f0954d6c0
1351522 WB_REASON_FOREIGN_FLUSH 0xffff969e76713340
2567437 WB_REASON_FOREIGN_FLUSH 0xffff9694ae208400
2954033 WB_REASON_FOREIGN_FLUSH 0xffff96a22d62cbc0
3008860 WB_REASON_FOREIGN_FLUSH 0xffff969eee8ce3c0
3337932 WB_REASON_FOREIGN_FLUSH 0xffff9695b45156c0
3348916 WB_REASON_FOREIGN_FLUSH 0xffff96a22c7a4f40
3345363 WB_REASON_FOREIGN_FLUSH 0xffff969e5d872800
3333581 WB_REASON_FOREIGN_FLUSH 0xffff969efd0f4600
3382225 WB_REASON_FOREIGN_FLUSH 0xffff969e770edcc0
3418770 WB_REASON_FOREIGN_FLUSH 0xffff96a252ceea40
3387648 WB_REASON_FOREIGN_FLUSH 0xffff96a3bda86340
3385420 WB_REASON_FOREIGN_FLUSH 0xffff969efc6eb280
3418730 WB_REASON_FOREIGN_FLUSH 0xffff96a348ab1040
3426155 WB_REASON_FOREIGN_FLUSH 0xffff969d90beac00
3397995 WB_REASON_FOREIGN_FLUSH 0xffff96a2d7288800
3293095 WB_REASON_FOREIGN_FLUSH 0xffff969dab423240
3293595 WB_REASON_FOREIGN_FLUSH 0xffff969c765ff400
3199511 WB_REASON_FOREIGN_FLUSH 0xffff969a72d5e680
3085016 WB_REASON_FOREIGN_FLUSH 0xffff969f0455e000
3035712 WB_REASON_FOREIGN_FLUSH 0xffff969d9bbf4b00
b. The writeback might severely throttled by wbt, with a speed
possibly less than 100kb/s, leading to a very long writeback time.
>>> wb.write_bandwidth
(unsigned long)24
>>> wb.write_bandwidth
(unsigned long)13
The wb_wait_for_completion() here is probably only used to prevent
use-after-free. Therefore, we manage 'done' separately and automatically
free it.
This allows us to remove wb_wait_for_completion() while preventing
the use-after-free issue.
Fixes: 97b27821b485 ("writeback, memcg: Implement foreign dirty flushing")
Signed-off-by: Julian Sun <sunjunchao@bytedance.com>
---
Changes in v4:
* Check done->cnt in memcg_cgwb_waitq_callback_fn().
* Code cleanups as Tejun suggested.
Changes in v3:
* Rename cgwb_frn_wq_entry to cgwb_frn_wait.
* Define memcg_cgwb_waitq_callback_fn() only when
CONFIG_CGROUP_WRITEBACK is defined.
* Embed wb_completion into struct cgwb_frn_wait.
Change in v2:
* Use custom waitq function to free resources
include/linux/memcontrol.h | 7 ++++-
mm/memcontrol.c | 53 ++++++++++++++++++++++++++++++++------
2 files changed, 51 insertions(+), 9 deletions(-)
diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
index 785173aa0739..b16bc4bd0ad0 100644
--- a/include/linux/memcontrol.h
+++ b/include/linux/memcontrol.h
@@ -157,11 +157,16 @@ struct mem_cgroup_thresholds {
*/
#define MEMCG_CGWB_FRN_CNT 4
+struct cgwb_frn_wait {
+ struct wb_completion done;
+ struct wait_queue_entry wq_entry;
+};
+
struct memcg_cgwb_frn {
u64 bdi_id; /* bdi->id of the foreign inode */
int memcg_id; /* memcg->css.id of foreign inode */
u64 at; /* jiffies_64 at the time of dirtying */
- struct wb_completion done; /* tracks in-flight foreign writebacks */
+ struct cgwb_frn_wait *wait; /* tracks in-flight foreign writebacks */
};
/*
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 8dd7fbed5a94..80257dba30f8 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -3459,7 +3459,7 @@ void mem_cgroup_track_foreign_dirty_slowpath(struct folio *folio,
frn->memcg_id == wb->memcg_css->id)
break;
if (time_before64(frn->at, oldest_at) &&
- atomic_read(&frn->done.cnt) == 1) {
+ atomic_read(&frn->wait->done.cnt) == 1) {
oldest = i;
oldest_at = frn->at;
}
@@ -3506,12 +3506,12 @@ void mem_cgroup_flush_foreign(struct bdi_writeback *wb)
* already one in flight.
*/
if (time_after64(frn->at, now - intv) &&
- atomic_read(&frn->done.cnt) == 1) {
+ atomic_read(&frn->wait->done.cnt) == 1) {
frn->at = 0;
trace_flush_foreign(wb, frn->bdi_id, frn->memcg_id);
cgroup_writeback_by_id(frn->bdi_id, frn->memcg_id,
WB_REASON_FOREIGN_FLUSH,
- &frn->done);
+ &frn->wait->done);
}
}
}
@@ -3702,13 +3702,29 @@ static void mem_cgroup_free(struct mem_cgroup *memcg)
__mem_cgroup_free(memcg);
}
+#ifdef CONFIG_CGROUP_WRITEBACK
+static int memcg_cgwb_waitq_callback_fn(struct wait_queue_entry *wq_entry, unsigned int mode,
+ int flags, void *key)
+{
+ struct cgwb_frn_wait *frn_wait = container_of(wq_entry,
+ struct cgwb_frn_wait, wq_entry);
+
+ if (!atomic_read(&frn_wait->done.cnt)) {
+ list_del(&wq_entry->entry);
+ kfree(frn_wait);
+ }
+
+ return 0;
+}
+#endif
+
static struct mem_cgroup *mem_cgroup_alloc(struct mem_cgroup *parent)
{
struct memcg_vmstats_percpu *statc;
struct memcg_vmstats_percpu __percpu *pstatc_pcpu;
struct mem_cgroup *memcg;
int node, cpu;
- int __maybe_unused i;
+ int __maybe_unused i = 0;
long error;
memcg = kmem_cache_zalloc(memcg_cachep, GFP_KERNEL);
@@ -3763,9 +3779,17 @@ static struct mem_cgroup *mem_cgroup_alloc(struct mem_cgroup *parent)
INIT_LIST_HEAD(&memcg->objcg_list);
#ifdef CONFIG_CGROUP_WRITEBACK
INIT_LIST_HEAD(&memcg->cgwb_list);
- for (i = 0; i < MEMCG_CGWB_FRN_CNT; i++)
- memcg->cgwb_frn[i].done =
+ for (i = 0; i < MEMCG_CGWB_FRN_CNT; i++) {
+ struct memcg_cgwb_frn *frn = &memcg->cgwb_frn[i];
+
+ frn->wait = kmalloc(sizeof(struct cgwb_frn_wait), GFP_KERNEL);
+ if (!frn->wait)
+ goto fail;
+
+ frn->wait->done =
__WB_COMPLETION_INIT(&memcg_cgwb_frn_waitq);
+ init_wait_func(&frn->wait->wq_entry, memcg_cgwb_waitq_callback_fn);
+ }
#endif
#ifdef CONFIG_TRANSPARENT_HUGEPAGE
spin_lock_init(&memcg->deferred_split_queue.split_queue_lock);
@@ -3775,6 +3799,10 @@ static struct mem_cgroup *mem_cgroup_alloc(struct mem_cgroup *parent)
lru_gen_init_memcg(memcg);
return memcg;
fail:
+#ifdef CONFIG_CGROUP_WRITEBACK
+ while (i--)
+ kfree(memcg->cgwb_frn[i].wait);
+#endif
mem_cgroup_id_remove(memcg);
__mem_cgroup_free(memcg);
return ERR_PTR(error);
@@ -3912,8 +3940,17 @@ static void mem_cgroup_css_free(struct cgroup_subsys_state *css)
int __maybe_unused i;
#ifdef CONFIG_CGROUP_WRITEBACK
- for (i = 0; i < MEMCG_CGWB_FRN_CNT; i++)
- wb_wait_for_completion(&memcg->cgwb_frn[i].done);
+ for (i = 0; i < MEMCG_CGWB_FRN_CNT; i++) {
+ struct cgwb_frn_wait *wait = memcg->cgwb_frn[i].wait;
+
+ /*
+ * Not necessary to wait for wb completion which might cause task hung,
+ * only used to free resources. See memcg_cgwb_waitq_callback_fn().
+ */
+ __add_wait_queue_entry_tail(wait->done.waitq, &wait->wq_entry);
+ if (atomic_dec_and_test(&wait->done.cnt))
+ wake_up_all(wait->done.waitq);
+ }
#endif
if (cgroup_subsys_on_dfl(memory_cgrp_subsys) && !cgroup_memory_nosocket)
static_branch_dec(&memcg_sockets_enabled_key);
--
2.39.5
^ permalink raw reply related [flat|nested] 2+ messages in thread
* Re: [PATCH v4] memcg: Don't wait writeback completion when release memcg.
2025-08-27 20:45 [PATCH v4] memcg: Don't wait writeback completion when release memcg Julian Sun
@ 2025-08-27 21:25 ` Tejun Heo
0 siblings, 0 replies; 2+ messages in thread
From: Tejun Heo @ 2025-08-27 21:25 UTC (permalink / raw)
To: Julian Sun; +Cc: cgroups, linux-mm, jack, muchun.song
On Thu, Aug 28, 2025 at 04:45:57AM +0800, Julian Sun wrote:
> Recently, we encountered the following hung task:
>
> INFO: task kworker/4:1:1334558 blocked for more than 1720 seconds.
> [Wed Jul 30 17:47:45 2025] Workqueue: cgroup_destroy css_free_rwork_fn
> [Wed Jul 30 17:47:45 2025] Call Trace:
> [Wed Jul 30 17:47:45 2025] __schedule+0x934/0xe10
> [Wed Jul 30 17:47:45 2025] ? complete+0x3b/0x50
> [Wed Jul 30 17:47:45 2025] ? _cond_resched+0x15/0x30
> [Wed Jul 30 17:47:45 2025] schedule+0x40/0xb0
> [Wed Jul 30 17:47:45 2025] wb_wait_for_completion+0x52/0x80
> [Wed Jul 30 17:47:45 2025] ? finish_wait+0x80/0x80
> [Wed Jul 30 17:47:45 2025] mem_cgroup_css_free+0x22/0x1b0
> [Wed Jul 30 17:47:45 2025] css_free_rwork_fn+0x42/0x380
> [Wed Jul 30 17:47:45 2025] process_one_work+0x1a2/0x360
> [Wed Jul 30 17:47:45 2025] worker_thread+0x30/0x390
> [Wed Jul 30 17:47:45 2025] ? create_worker+0x1a0/0x1a0
> [Wed Jul 30 17:47:45 2025] kthread+0x110/0x130
> [Wed Jul 30 17:47:45 2025] ? __kthread_cancel_work+0x40/0x40
> [Wed Jul 30 17:47:45 2025] ret_from_fork+0x1f/0x30
>
> The direct cause is that memcg spends a long time waiting for dirty page
> writeback of foreign memcgs during release.
>
> The root causes are:
> a. The wb may have multiple writeback tasks, containing millions
> of dirty pages, as shown below:
>
> >>> for work in list_for_each_entry("struct wb_writeback_work", \
> wb.work_list.address_of_(), "list"):
> ... print(work.nr_pages, work.reason, hex(work))
> ...
> 900628 WB_REASON_FOREIGN_FLUSH 0xffff969e8d956b40
> 1116521 WB_REASON_FOREIGN_FLUSH 0xffff9698332a9540
> 1275228 WB_REASON_FOREIGN_FLUSH 0xffff969d9b444bc0
> 1099673 WB_REASON_FOREIGN_FLUSH 0xffff969f0954d6c0
> 1351522 WB_REASON_FOREIGN_FLUSH 0xffff969e76713340
> 2567437 WB_REASON_FOREIGN_FLUSH 0xffff9694ae208400
> 2954033 WB_REASON_FOREIGN_FLUSH 0xffff96a22d62cbc0
> 3008860 WB_REASON_FOREIGN_FLUSH 0xffff969eee8ce3c0
> 3337932 WB_REASON_FOREIGN_FLUSH 0xffff9695b45156c0
> 3348916 WB_REASON_FOREIGN_FLUSH 0xffff96a22c7a4f40
> 3345363 WB_REASON_FOREIGN_FLUSH 0xffff969e5d872800
> 3333581 WB_REASON_FOREIGN_FLUSH 0xffff969efd0f4600
> 3382225 WB_REASON_FOREIGN_FLUSH 0xffff969e770edcc0
> 3418770 WB_REASON_FOREIGN_FLUSH 0xffff96a252ceea40
> 3387648 WB_REASON_FOREIGN_FLUSH 0xffff96a3bda86340
> 3385420 WB_REASON_FOREIGN_FLUSH 0xffff969efc6eb280
> 3418730 WB_REASON_FOREIGN_FLUSH 0xffff96a348ab1040
> 3426155 WB_REASON_FOREIGN_FLUSH 0xffff969d90beac00
> 3397995 WB_REASON_FOREIGN_FLUSH 0xffff96a2d7288800
> 3293095 WB_REASON_FOREIGN_FLUSH 0xffff969dab423240
> 3293595 WB_REASON_FOREIGN_FLUSH 0xffff969c765ff400
> 3199511 WB_REASON_FOREIGN_FLUSH 0xffff969a72d5e680
> 3085016 WB_REASON_FOREIGN_FLUSH 0xffff969f0455e000
> 3035712 WB_REASON_FOREIGN_FLUSH 0xffff969d9bbf4b00
>
> b. The writeback might severely throttled by wbt, with a speed
> possibly less than 100kb/s, leading to a very long writeback time.
>
> >>> wb.write_bandwidth
> (unsigned long)24
> >>> wb.write_bandwidth
> (unsigned long)13
>
> The wb_wait_for_completion() here is probably only used to prevent
> use-after-free. Therefore, we manage 'done' separately and automatically
> free it.
>
> This allows us to remove wb_wait_for_completion() while preventing
> the use-after-free issue.
>
> Fixes: 97b27821b485 ("writeback, memcg: Implement foreign dirty flushing")
> Signed-off-by: Julian Sun <sunjunchao@bytedance.com>
Acked-by: Tejun Heo <tj@kernel.org>
Thanks.
--
tejun
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2025-08-27 21:25 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-08-27 20:45 [PATCH v4] memcg: Don't wait writeback completion when release memcg Julian Sun
2025-08-27 21:25 ` Tejun Heo
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).