[lkml]   [2019]   [Oct]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Patch in this message
Subject[PATCH] cgroup, blkcg: prevent dirty inodes to pin dying memory cgroups
This is a RFC patch, which is not intended to be merged as is,
but hopefully will start a discussion which can result in a good
solution for the described problem.


We've noticed that the number of dying cgroups on our production hosts
tends to grow with the uptime. This time it's caused by the writeback

An inode which is getting dirty for the first time is associated
with the wb structure (look at __inode_attach_wb()). It can later
be switched to another wb under some conditions (e.g. some other
cgroup is writing a lot of data to the same inode), but generally
stays associated up to the end of life of the inode structure.

The problem is that the wb structure holds a reference to the original
memory cgroup. So if the inode was dirty once, it has a good chance
to pin down the original memory cgroup.

An example from the real life: some service runs periodically and
updates rpm packages. Each time in a new memory cgroup. Installed
.so files are heavily used by other cgroups, so corresponding inodes
tend to stay alive for a long. So do pinned memory cgroups.
In production I've seen many hosts with 1-2 thousands of dying

This is not the first problem with the dying memory cgroups. As
always, the problem is with their relative size: memory cgroups
are large objects, easily 100x-1000x larger that inodes. So keeping
a couple of thousands of dying cgroups in memory without a good reason
(what we easily do with inodes) is quite costly (and is measured
in tens and hundreds of Mb).

One possible approach to this problem is to switch inodes associated
with dying wbs to the root wb. Switching is a best effort operation
which can fail silently, so unfortunately we can't run once over a
list of associated inodes (even if we'd have such a list). So we
really have to scan all inodes.

In the proposed patch I schedule a work on each memory cgroup
deletion, which is probably too often. Alternatively, we can do it
periodically under some conditions (e.g. the number of dying memory
cgroups is larger than X). So it's basically a gc run.

I wonder if there are any better ideas?

Signed-off-by: Roman Gushchin <>
fs/fs-writeback.c | 29 +++++++++++++++++++++++++++++
mm/memcontrol.c | 5 +++++
2 files changed, 34 insertions(+)

diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c
index 542b02d170f8..4bbc9a200b2c 100644
--- a/fs/fs-writeback.c
+++ b/fs/fs-writeback.c
@@ -545,6 +545,35 @@ static void inode_switch_wbs(struct inode *inode, int new_wb_id)

+static void reparent_dirty_inodes_one_sb(struct super_block *sb, void *arg)
+ struct inode *inode, *next;
+ spin_lock(&sb->s_inode_list_lock);
+ list_for_each_entry_safe(inode, next, &sb->s_inodes, i_sb_list) {
+ spin_lock(&inode->i_lock);
+ if (inode->i_state & (I_NEW | I_FREEING | I_WILL_FREE)) {
+ spin_unlock(&inode->i_lock);
+ continue;
+ }
+ if (inode->i_wb && wb_dying(inode->i_wb)) {
+ spin_unlock(&inode->i_lock);
+ inode_switch_wbs(inode, root_mem_cgroup->;
+ continue;
+ }
+ spin_unlock(&inode->i_lock);
+ }
+ spin_unlock(&sb->s_inode_list_lock);
+void reparent_dirty_inodes(struct work_struct *work)
+ iterate_supers(reparent_dirty_inodes_one_sb, NULL);
* wbc_attach_and_unlock_inode - associate wbc with target inode and unlock it
* @wbc: writeback_control of interest
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 9ec5e12486a7..ea8bc8d1403b 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -4911,6 +4911,9 @@ static int mem_cgroup_css_online(struct cgroup_subsys_state *css)
return 0;

+extern void reparent_dirty_inodes(struct work_struct *w);
+static DECLARE_WORK(dirty_work, reparent_dirty_inodes);
static void mem_cgroup_css_offline(struct cgroup_subsys_state *css)
struct mem_cgroup *memcg = mem_cgroup_from_css(css);
@@ -4934,6 +4937,8 @@ static void mem_cgroup_css_offline(struct cgroup_subsys_state *css)

+ schedule_work(&dirty_work);

 \ /
  Last update: 2019-10-05 00:11    [W:0.126 / U:3.752 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site