summaryrefslogtreecommitdiffstats
path: root/block
diff options
context:
space:
mode:
authorDave Chinner <david@fromorbit.com>2012-04-23 17:54:32 +1000
committerBen Myers <bpm@sgi.com>2012-05-14 16:20:34 -0500
commit4c2d542f2e786537db33b613d5199dc6d69a96da (patch)
treeeeca27ca63e519981e8d4f2ab1bcf8230f5e598e /block
parent04913fdd91f342e537005ef1233f98068b925a7f (diff)
downloadlinux-4c2d542f2e786537db33b613d5199dc6d69a96da.tar.bz2
xfs: Do background CIL flushes via a workqueue
Doing background CIL flushes adds significant latency to whatever async transaction that triggers it. To avoid blocking async transactions on things like waiting for log buffer IO to complete, move the CIL push off into a workqueue. By moving the push work into a workqueue, we remove all the latency that the commit adds from the foreground transaction commit path. This also means that single threaded workloads won't do the CIL push procssing, leaving them more CPU to do more async transactions. To do this, we need to keep track of the sequence number we have pushed work for. This avoids having many transaction commits attempting to schedule work for the same sequence, and ensures that we only ever have one push (background or forced) in progress at a time. It also means that we don't need to take the CIL lock in write mode to check for potential background push races, which reduces lock contention. To avoid potential issues with "smart" IO schedulers, don't use the workqueue for log force triggered flushes. Instead, do them directly so that the log IO is done directly by the process issuing the log force and so doesn't get stuck on IO elevator queue idling incorrectly delaying the log IO from the workqueue. Signed-off-by: Dave Chinner <dchinner@redhat.com> Reviewed-by: Mark Tinguely <tinguely@sgi.com> Signed-off-by: Ben Myers <bpm@sgi.com>
Diffstat (limited to 'block')
0 files changed, 0 insertions, 0 deletions