From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bob Peterson Date: Tue, 1 Aug 2017 13:00:51 -0400 (EDT) Subject: [Cluster-devel] [PATCH v3 0/4] GFS2 shrinker deadlock In-Reply-To: <20170801000022.13295-1-agruenba@redhat.com> References: <20170801000022.13295-1-agruenba@redhat.com> Message-ID: <279093531.37420353.1501606851440.JavaMail.zimbra@redhat.com> List-Id: To: cluster-devel.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit ----- Original Message ----- | With the recent gl_object fixes and an additional reference counting bug | fixed in this patch queue, these four remaining shrinker deadlock | avoidance patches now seem ready for mainline. | | As explained in the previous posting of this patch queue, when inodes | are evicted, GFS2 currently calls into DLM. Inode eviction can be | triggered by memory pressure, in the context of a random user-space | process. If DLM happens to block in the process in question (for | example, it that process is a fence agent), GFS2 and DLM will deadlock. | | This patch queue stops GFS2 from calling into DLM on the inode evict | path under memory pressure. It does so by first decoupling destroying | inodes and putting their associated glocks, which is what ends up | calling into DLM. Second, when under memory pressure, it moves putting | glocks into work queue context where it cannot block DLM. Third, when | gfs2_drop_inode determines that an inode's link count has hit zero under | memory pressure, it puts that inode on the delete workqueue (and keeps | the inode in the icache) instead of causing gfs2_evict_inode to delete | the inode immediately. The delete workqueue will not be processed under | memory pressure, so deleting inodes from there is safe. | | Thanks, | Andreas | | Andreas Gruenbacher (4): | gfs2: gfs2_glock_get: Wait on freeing glocks | gfs2: Get rid of gfs2_set_nlink | gfs2: gfs2_evict_inode: Put glocks asynchronously | gfs2: Defer deleting inodes under memory pressure | | fs/gfs2/glock.c | 135 | +++++++++++++++++++++++++++++++++++++++++++++++--------- | fs/gfs2/glock.h | 2 + | fs/gfs2/glops.c | 28 +----------- | fs/gfs2/super.c | 43 +++++++++++++++++- | 4 files changed, 157 insertions(+), 51 deletions(-) | | -- | 2.13.3 | | Hi, These all look good. This was a major problem to get fixed. Thanks for all your effort. All four patches are now pushed to the for-next branch of the linux-gfs2 tree: https://git.kernel.org/pub/scm/linux/kernel/git/gfs2/linux-gfs2.git/commit/fs/gfs2?h=for-next&id=56a365beda9ef5121eab1d8c5dfe8742b4e69d48 https://git.kernel.org/pub/scm/linux/kernel/git/gfs2/linux-gfs2.git/commit/fs/gfs2?h=for-next&id=325c8fe97257c68c90c68cc6bde61e9825de3361 https://git.kernel.org/pub/scm/linux/kernel/git/gfs2/linux-gfs2.git/commit/fs/gfs2?h=for-next&id=6e036cbbd6909b8c8e53cd399051c699379e4818 https://git.kernel.org/pub/scm/linux/kernel/git/gfs2/linux-gfs2.git/commit/fs/gfs2?h=for-next&id=0d0e409c22b6b53e1ed1a57b1551e144e0afae79 Regards, Bob Peterson Red Hat File Systems