]> git.baikalelectronics.ru Git - kernel.git/commit
xfs: ratelimit inode flush on buffered write ENOSPC
authorDarrick J. Wong <darrick.wong@oracle.com>
Fri, 27 Mar 2020 15:49:44 +0000 (08:49 -0700)
committerDarrick J. Wong <darrick.wong@oracle.com>
Tue, 31 Mar 2020 15:41:45 +0000 (08:41 -0700)
commit8056c99cd46be0a5f1b8da7d179592277f13e9b9
treea830ec2428924b8c2fec2eb98923c5daf27d26bf
parent6db1e57ff6ac8dbac66bdfbc51923643a7f25235
xfs: ratelimit inode flush on buffered write ENOSPC

A customer reported rcu stalls and softlockup warnings on a computer
with many CPU cores and many many more IO threads trying to write to a
filesystem that is totally out of space.  Subsequent analysis pointed to
the many many IO threads calling xfs_flush_inodes -> sync_inodes_sb,
which causes a lot of wb_writeback_work to be queued.  The writeback
worker spends so much time trying to wake the many many threads waiting
for writeback completion that it trips the softlockup detector, and (in
this case) the system automatically reboots.

In addition, they complain that the lengthy xfs_flush_inodes scan traps
all of those threads in uninterruptible sleep, which hampers their
ability to kill the program or do anything else to escape the situation.

If there's thousands of threads trying to write to files on a full
filesystem, each of those threads will start separate copies of the
inode flush scan.  This is kind of pointless since we only need one
scan, so rate limit the inode flush.

Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
fs/xfs/xfs_mount.h
fs/xfs/xfs_super.c