Hi, Per Eric's request, I forward this discussion to the list first. My first answers are inside -----Original Message----- From: Eric Sandeen Sent: Tuesday, March 16, 2021 10:18 PM To: David Mozes Subject: Re: Mail from David.Mozes regarding fs: avoid softlockups in s_inodes iterators commit On 3/16/21 3:02 PM, David Mozes wrote: > Hi Eric, > > I hope you are all well. > > I am writing to you since I think you are interested in this case. > This really should go to linux-fsdevel@vger.kernel.org but feel free to cc: me A few things you'd want to clarify first, though. What is the testcase? David> it can be consider as very high load read/write iscsi traffic based on SCST application. > [122656.730235] sh (27931): drop_caches: 3 When/why are you running drop_caches in the first place? David > Not sure yet, Will check. > 5.4.8 vanilla kernel it custom Is it vanilla, or is it custom? 5.4.8 or 5.4.80? David> 5.4.80 small custom as I mantion. > While looking at the code, I suspected on thecond_resched(); in > /fs/drop_caches.c file. that you moved on commit > 04646aebd30b99f2cfa0182435a2ec252fcb16d0 > > I comment out the cond_resched(), and everything is running just fine for ten days. I moved it; that shouldn't matter. You removed it - that will change behavior. What happens if you just move it back? i.e. my patch did: diff --git a/fs/drop_caches.c b/fs/drop_caches.c index d31b6c72b476..dc1a1d5d825b 100644 --- a/fs/drop_caches.c +++ b/fs/drop_caches.c @@ -35,11 +35,11 @@ static void drop_pagecache_sb(struct super_block *sb, void *unused) spin_unlock(&inode->i_lock); spin_unlock(&sb->s_inode_list_lock); - cond_resched(); invalidate_mapping_pages(inode->i_mapping, 0, -1); iput(toput_inode); toput_inode = inode; + cond_resched(); spin_lock(&sb->s_inode_list_lock); } spin_unlock(&sb->s_inode_list_lock); What happens if you don't delete the cond_resched, but move it back up above invalidate_mapping_pages? David> Will test and update Thx David -Eric