Commit e240c183 authored by Shaohua Li's avatar Shaohua Li Committed by NeilBrown

raid5: get_active_stripe avoids device_lock

For sequential workload (or request size big workload), get_active_stripe can
find cached stripe. In this case, we always hold device_lock, which exposes a
lot of lock contention for such workload. If stripe count isn't 0, we don't
need hold the lock actually, since we just increase its count. And this is the
hot code path for such workload. Unfortunately we must delete the BUG_ON.
Signed-off-by: default avatarShaohua Li <shli@fusionio.com>
Signed-off-by: default avatarNeilBrown <neilb@suse.de>
parent 27c0f68f
...@@ -679,14 +679,9 @@ get_active_stripe(struct r5conf *conf, sector_t sector, ...@@ -679,14 +679,9 @@ get_active_stripe(struct r5conf *conf, sector_t sector,
init_stripe(sh, sector, previous); init_stripe(sh, sector, previous);
atomic_inc(&sh->count); atomic_inc(&sh->count);
} }
} else { } else if (!atomic_inc_not_zero(&sh->count)) {
spin_lock(&conf->device_lock); spin_lock(&conf->device_lock);
if (atomic_read(&sh->count)) { if (!atomic_read(&sh->count)) {
BUG_ON(!list_empty(&sh->lru)
&& !test_bit(STRIPE_EXPANDING, &sh->state)
&& !test_bit(STRIPE_ON_UNPLUG_LIST, &sh->state)
);
} else {
if (!test_bit(STRIPE_HANDLE, &sh->state)) if (!test_bit(STRIPE_HANDLE, &sh->state))
atomic_inc(&conf->active_stripes); atomic_inc(&conf->active_stripes);
BUG_ON(list_empty(&sh->lru) && BUG_ON(list_empty(&sh->lru) &&
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment