summaryrefslogtreecommitdiffstats
path: root/tools
diff options
context:
space:
mode:
authorDave Chinner <dchinner@redhat.com>2010-08-24 11:40:03 +1000
committerDave Chinner <david@fromorbit.com>2010-08-24 11:40:03 +1000
commita44f13edf0ebb4e41942d0f16ca80489dcf6659d (patch)
tree42bcbee56a62851e969292033efd600cced80ca5 /tools
parent1a387d3be2b30c90f20d49a3497a8fc0693a9d18 (diff)
xfs: Reduce log force overhead for delayed logging
Delayed logging adds some serialisation to the log force process to ensure that it does not deference a bad commit context structure when determining if a CIL push is necessary or not. It does this by grabing the CIL context lock exclusively, then dropping it before pushing the CIL if necessary. This causes serialisation of all log forces and pushes regardless of whether a force is necessary or not. As a result fsync heavy workloads (like dbench) can be significantly slower with delayed logging than without. To avoid this penalty, copy the current sequence from the context to the CIL structure when they are swapped. This allows us to do unlocked checks on the current sequence without having to worry about dereferencing context structures that may have already been freed. Hence we can remove the CIL context locking in the forcing code and only call into the push code if the current context matches the sequence we need to force. By passing the sequence into the push code, we can check the sequence again once we have the CIL lock held exclusive and abort if the sequence has already been pushed. This avoids a lock round-trip and unnecessary CIL pushes when we have racing push calls. The result is that the regression in dbench performance goes away - this change improves dbench performance on a ramdisk from ~2100MB/s to ~2500MB/s. This compares favourably to not using delayed logging which retuns ~2500MB/s for the same workload. Signed-off-by: Dave Chinner <dchinner@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de>
Diffstat (limited to 'tools')
0 files changed, 0 insertions, 0 deletions