diff options
author | Dan Williams <dan.j.williams@intel.com> | 2007-01-02 13:52:30 -0700 |
---|---|---|
committer | Dan Williams <dan.j.williams@intel.com> | 2007-07-13 08:06:16 -0700 |
commit | d84e0f10d38393f617227f0c831a99c69294651f (patch) | |
tree | 5d0836f024f1f13ac6f1b2b2d3004244cb0fa649 /net | |
parent | 91c00924846a0034020451c280c76baa4299f9dc (diff) | |
download | linux-3.10-d84e0f10d38393f617227f0c831a99c69294651f.tar.gz linux-3.10-d84e0f10d38393f617227f0c831a99c69294651f.tar.bz2 linux-3.10-d84e0f10d38393f617227f0c831a99c69294651f.zip |
md: common infrastructure for running operations with raid5_run_ops
All the handle_stripe operations that are to be transitioned to use
raid5_run_ops need a method to coherently gather work under the stripe-lock
and hand that work off to raid5_run_ops. The 'get_stripe_work' routine
runs under the lock to read all the bits in sh->ops.pending that do not
have the corresponding bit set in sh->ops.ack. This modified 'pending'
bitmap is then passed to raid5_run_ops for processing.
The transition from 'ack' to 'completion' does not need similar protection
as the existing release_stripe infrastructure will guarantee that
handle_stripe will run again after a completion bit is set, and
handle_stripe can tolerate a sh->ops.completed bit being set while the lock
is held.
A call to async_tx_issue_pending_all() is added to raid5d to kick the
offload engines once all pending stripe operations work has been submitted.
This enables batching of the submission and completion of operations.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Acked-By: NeilBrown <neilb@suse.de>
Diffstat (limited to 'net')
0 files changed, 0 insertions, 0 deletions