| title: | Re PATCH 3 5 dm relax ordering of bio bas |
|
On Mon, Aug 30 2010 at 5:58am -0400,
Tejun Heo <tj@xxxxxxxxxx wrote:
Unlike REQ_HARDBARRIER, REQ_FLUSH/FUA doesnt mandate any ordering
against other bios. This patch relaxes ordering around flushes.
* A flush bio is no longer deferred to workqueue directly. Its
processed like other bios but __split_and_process_bio() uses
md- flush_bio as the clone source. md- flush_bio is initialized to
empty flush during md initialization and shared for all flushes.
* When dec_pending() detects that a flush has completed, it checks
whether the original bio has data. If so, the bio is queued to the
deferred list w/ REQ_FLUSH cleared; otherwise, its completed.
* As flush sequencing is handled in the usual issue/completion path,
dm_wq_work() no longer needs to handle flushes differently. Now its
only responsibility is re-issuing deferred bios the same way as
_dm_request() would. REQ_FLUSH handling logic including
process_flush() is dropped.
* Theres no reason for queue_io() and dm_wq_work() write lock
dm- io_lock. queue_io() now only uses md- deferred_lock and
dm_wq_work() read locks dm- io_lock.
* bios no longer need to be queued on the deferred list while a flush
is in progress making DMF_QUEUE_IO_TO_THREAD unncessary. Drop it.
This avoids stalling the device during flushes and simplifies the
implementation.
Signed-off-by: Tejun Heo <tj@xxxxxxxxxx
Looks good overall.
@@ -144,11 +143,6 @@ struct mapped_device {
spinlock_t deferred_lock;
/*
- * An error from the flush request currently being processed.
- */
- int flush_error;
-
- /*
* Protect barrier_error from concurrent endio processing
* in request-based dm.
*/
Could you please document why it is OK to remove flush_error in the
patch header? The -EOPNOTSUPP handling removal (done in patch 2)
obviously helps enable this but it is not clear how the
num_flush_requests flushes that __clone_and_map_flush() generates do
not need explicit DM error handling.
Other than that.
Acked-by: Mike Snitzer <snitzer@xxxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at rel="nofollow" vger.kernel.org/majordomo-info.html vger.kernel.org/majordomo-info.html
|
