diff options
author | Dave Chinner <dchinner@redhat.com> | 2014-02-27 06:40:42 +0100 |
---|---|---|
committer | Dave Chinner <david@fromorbit.com> | 2014-02-27 06:40:42 +0100 |
commit | f876e44603ad091c840a5fae5b0753bbb421c037 (patch) | |
tree | db8d96b382301a8cfa4dd3bd0325f9b108eb7827 /fs/xfs/xfs_bit.c | |
parent | Linus 3.14-rc1 (diff) | |
download | linux-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