summaryrefslogtreecommitdiffstats
path: root/fs/xfs/xfs_bit.c
diff options
context:
space:
mode:
authorDave Chinner <dchinner@redhat.com>2014-02-27 06:40:42 +0100
committerDave Chinner <david@fromorbit.com>2014-02-27 06:40:42 +0100
commitf876e44603ad091c840a5fae5b0753bbb421c037 (patch)
treedb8d96b382301a8cfa4dd3bd0325f9b108eb7827 /fs/xfs/xfs_bit.c
parentLinus 3.14-rc1 (diff)
downloadlinux-f876e44603ad091c840a5fae5b0753bbb421c037.tar.xz
linux-f876e44603ad091c840a5fae5b0753bbb421c037.zip
xfs: always do log forces via the workqueue
Log forces can occur deep in the call chain when we have relatively little stack free. Log forces can also happen at close to the call chain leaves (e.g. xfs_buf_lock()) and hence we can trigger IO from places where we really don't want to add more stack overhead. This stack overhead occurs because log forces do foreground CIL pushes (xlog_cil_push_foreground()) rather than waking the background push wq and waiting for the for the push to complete. This foreground push was done to avoid confusing the CFQ Io scheduler when fsync()s were issued, as it has trouble dealing with dependent IOs being issued from different process contexts. Avoiding blowing the stack is much more critical than performance optimisations for CFQ, especially as we've been recommending against the use of CFQ for XFS since 3.2 kernels were release because of it's problems with multi-threaded IO workloads. Hence convert xlog_cil_push_foreground() to move the push work to the CIL workqueue. We already do the waiting for the push to complete in xlog_cil_force_lsn(), so there's nothing else we need to modify to make this work. Signed-off-by: Dave Chinner <dchinner@redhat.com> Reviewed-by: Brian Foster <bfoster@redhat.com> Signed-off-by: Dave Chinner <david@fromorbit.com>
Diffstat (limited to 'fs/xfs/xfs_bit.c')
0 files changed, 0 insertions, 0 deletions