On Thu, 28 May 2015 17:33:46 -0700 Shaohua Li <shli@xxxxxx> 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@xxxxxx>
> ---
> 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:
pgpSSpNQoJK9C.pgp
Description: OpenPGP digital signature
