mirror of
https://github.com/Fishwaldo/Star64_linux.git
synced 2025-07-23 15:27:29 +00:00
raid5: make release_stripe lockless
release_stripe still has big lock contention. We just add the stripe to a llist without taking device_lock. We let the raid5d thread to do the real stripe release, which must hold device_lock anyway. In this way, release_stripe doesn't hold any locks. The side effect is the released stripes order is changed. But sounds not a big deal, stripes are never handled in order. And I thought block layer can already do nice request merge, which means order isn't that important. I kept the unplug release batch, which is unnecessary with this patch from lock contention avoid point of view, and actually if we delete it, the stripe_head release_list and lru can share storage. But the unplug release batch is also helpful for request merge. We probably can delay wakeup raid5d till unplug, but I'm still afraid of the case which raid5d is running. Signed-off-by: Shaohua Li <shli@fusionio.com> Signed-off-by: NeilBrown <neilb@suse.de>
This commit is contained in:
parent
260fa034ef
commit
773ca82fa1
2 changed files with 49 additions and 3 deletions
|
@ -197,6 +197,7 @@ enum reconstruct_states {
|
|||
struct stripe_head {
|
||||
struct hlist_node hash;
|
||||
struct list_head lru; /* inactive_list or handle_list */
|
||||
struct llist_node release_list;
|
||||
struct r5conf *raid_conf;
|
||||
short generation; /* increments with every
|
||||
* reshape */
|
||||
|
@ -321,6 +322,7 @@ enum {
|
|||
STRIPE_OPS_REQ_PENDING,
|
||||
STRIPE_ON_UNPLUG_LIST,
|
||||
STRIPE_DISCARD,
|
||||
STRIPE_ON_RELEASE_LIST,
|
||||
};
|
||||
|
||||
/*
|
||||
|
@ -445,6 +447,7 @@ struct r5conf {
|
|||
*/
|
||||
atomic_t active_stripes;
|
||||
struct list_head inactive_list;
|
||||
struct llist_head released_stripes;
|
||||
wait_queue_head_t wait_for_stripe;
|
||||
wait_queue_head_t wait_for_overlap;
|
||||
int inactive_blocked; /* release of inactive stripes blocked,
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue