From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeff Layton Subject: Re: [PATCH v2] vfs: don't softlockup when evicting inodes Date: Sun, 21 Dec 2014 07:18:00 -0500 Message-ID: <20141221071800.168842f7@synchrony.poochiereds.net> References: <1419003280-14401-1-git-send-email-jbacik@fb.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: , To: Josef Bacik Return-path: Received: from mail-qc0-f179.google.com ([209.85.216.179]:51397 "EHLO mail-qc0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751298AbaLUMSF (ORCPT ); Sun, 21 Dec 2014 07:18:05 -0500 Received: by mail-qc0-f179.google.com with SMTP id c9so2473478qcz.10 for ; Sun, 21 Dec 2014 04:18:05 -0800 (PST) In-Reply-To: <1419003280-14401-1-git-send-email-jbacik@fb.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Fri, 19 Dec 2014 10:34:40 -0500 Josef Bacik wrote: > If I run an fs_mark job that creates millions of empty files and then > immediately unmount the file system I will get a softlockup during unmount. > This box has ~140gb of RAM so we never hit sufficient memory pressure to evict > enough inodes during the runtime of the benchmark, which means I see around 80 > million inodes being evicted at unmount time. With this patch my box no longer > softlocks up. Thanks, > > Signed-off-by: Josef Bacik > --- > V1->V2: > -Still occasionally saw a softlockup in evict_inodes so add a cond_resched_lock > to that case as well. > > fs/inode.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/fs/inode.c b/fs/inode.c > index ad60555..f266765 100644 > --- a/fs/inode.c > +++ b/fs/inode.c > @@ -581,6 +581,7 @@ static void dispose_list(struct list_head *head) > list_del_init(&inode->i_lru); > > evict(inode); > + cond_resched(); > } > } > > @@ -613,6 +614,7 @@ void evict_inodes(struct super_block *sb) > inode_lru_list_del(inode); > spin_unlock(&inode->i_lock); > list_add(&inode->i_lru, &dispose); > + cond_resched_lock(&inode_sb_list_lock); > } > spin_unlock(&inode_sb_list_lock); > Is that safe? What guarantees that the next entry in the list (that is, the one already prefetched by list_for_each_entry_safe) will still be there once you drop and reacquire the lock? -- Jeff Layton