Re: [PATCH 2/4] raid5: grown at least NR_STRIPE_HASH_LOCKS stripes

[NeilBrown <neilb@suse.de>]

[-- Attachment #1: Type: text/plain, Size: 1627 bytes --]

On Thu, 28 May 2015 17:33:46 -0700 Shaohua Li <shli@fb.com> wrote:

> stripes are in hash list. If we are waiting for a free stripe, we must
> make sure there is free stripe in corresponding hash list. To do this,
> we simpliy allocate at lease NR_STRIPE_HASH_LOCKS stripes at runtime
> stripe allocation.
> 
> Signed-off-by: Shaohua Li <shli@fb.com>
> ---
>  drivers/md/raid5.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
> index bfa2042..0cceb71 100644
> --- a/drivers/md/raid5.c
> +++ b/drivers/md/raid5.c
> @@ -5867,7 +5867,9 @@ static void raid5d(struct md_thread *thread)
>  
>  	spin_unlock_irq(&conf->device_lock);
>  	if (test_and_clear_bit(R5_ALLOC_MORE, &conf->cache_state)) {
> -		grow_one_stripe(conf, __GFP_NOWARN);
> +		int i;
> +		for (i = 0; i < NR_STRIPE_HASH_LOCKS; i++)
> +			grow_one_stripe(conf, __GFP_NOWARN);
>  		/* Set flag even if allocation failed.  This helps
>  		 * slow down allocation requests when mem is short
>  		 */

Again, if R5_ALLOC_MORE is just a hint, it certainly isn't true that we
"must" make sure there are free stripes.
It's fairly important that the pool of stripes grows slowly.  I don't think
it matters a lot how slowly, but on a busy array it should grow steadily
until it hits an equilibrium, and making that happen a bit faster doesn't
seem necessary.

Think of R5_ALLOC_MORE like a gentle push towards allocating more strips.  It
doesn't matter if it fails, and if it is really important there will be
plenty more gentle pushes coming.

Thanks,
NeilBrown


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 811 bytes --]