public inbox for linux-raid@vger.kernel.org
 help / color / mirror / Atom feed
From: Paul Menzel <pmenzel@molgen.mpg.de>
To: Yu Kuai <yukuai1@huaweicloud.com>
Cc: song@kernel.org, logang@deltatee.com, guoqing.jiang@linux.dev,
	linux-raid@vger.kernel.org, linux-kernel@vger.kernel.org,
	yukuai3@huawei.com, yi.zhang@huawei.com
Subject: Re: [PATCH v2 1/4] md/raid10: cleanup wait_barrier()
Date: Wed, 14 Sep 2022 08:36:43 +0200	[thread overview]
Message-ID: <0b67df9e-7f64-e710-5928-2098ed8d0f2d@molgen.mpg.de> (raw)
In-Reply-To: <20220914014914.398712-2-yukuai1@huaweicloud.com>

Dear Yu,


Thank you for the improved patch. Three minor nits.

Am 14.09.22 um 03:49 schrieb Yu Kuai:
> From: Yu Kuai <yukuai3@huawei.com>

In the summary/title, I’d spell *Clean up* with a space. Maybe even use:

md/raid10: Factor out code from wait_barrier() to stop_waiting_barrier()

> Currently the nasty condition is wait_barrier() is hard to read. This
> patch factor out the condition into a function.

The first *is* above can be removed, and factor*s* needs an s.
> There are no functional changes.
> 
> Signed-off-by: Yu Kuai <yukuai3@huawei.com>
> ---
>   drivers/md/raid10.c | 56 ++++++++++++++++++++++++++-------------------
>   1 file changed, 32 insertions(+), 24 deletions(-)
> 
> diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c
> index 64d6e4cd8a3a..56458a53043d 100644
> --- a/drivers/md/raid10.c
> +++ b/drivers/md/raid10.c
> @@ -957,44 +957,52 @@ static void lower_barrier(struct r10conf *conf)
>   	wake_up(&conf->wait_barrier);
>   }
>   
> +static bool stop_waiting_barrier(struct r10conf *conf)
> +{
> +	/* barrier is dropped */
> +	if (!conf->barrier)
> +		return true;
> +
> +	/*
> +	 * If there are already pending requests (preventing the barrier from
> +	 * rising completely), and the pre-process bio queue isn't empty, then
> +	 * don't wait, as we need to empty that queue to get the nr_pending
> +	 * count down.
> +	 */
> +	if (atomic_read(&conf->nr_pending)) {
> +		struct bio_list *bio_list = current->bio_list;
> +
> +		if (bio_list && (!bio_list_empty(&bio_list[0]) ||
> +				 !bio_list_empty(&bio_list[1])))
> +			return true;
> +	}
> +
> +	/* move on if recovery thread is blocked by us */
> +	if (conf->mddev->thread->tsk == current &&
> +	    test_bit(MD_RECOVERY_RUNNING, &conf->mddev->recovery) &&
> +	    conf->nr_queued > 0)
> +		return true;
> +
> +	return false;
> +}
> +
>   static bool wait_barrier(struct r10conf *conf, bool nowait)
>   {
>   	bool ret = true;
>   
>   	spin_lock_irq(&conf->resync_lock);
>   	if (conf->barrier) {
> -		struct bio_list *bio_list = current->bio_list;
> -		conf->nr_waiting++;
> -		/* Wait for the barrier to drop.
> -		 * However if there are already pending
> -		 * requests (preventing the barrier from
> -		 * rising completely), and the
> -		 * pre-process bio queue isn't empty,
> -		 * then don't wait, as we need to empty
> -		 * that queue to get the nr_pending
> -		 * count down.
> -		 */
>   		/* Return false when nowait flag is set */
>   		if (nowait) {
>   			ret = false;
>   		} else {
> +			conf->nr_waiting++;
>   			raid10_log(conf->mddev, "wait barrier");
>   			wait_event_lock_irq(conf->wait_barrier,
> -					    !conf->barrier ||
> -					    (atomic_read(&conf->nr_pending) &&
> -					     bio_list &&
> -					     (!bio_list_empty(&bio_list[0]) ||
> -					      !bio_list_empty(&bio_list[1]))) ||
> -					     /* move on if recovery thread is
> -					      * blocked by us
> -					      */
> -					     (conf->mddev->thread->tsk == current &&
> -					      test_bit(MD_RECOVERY_RUNNING,
> -						       &conf->mddev->recovery) &&
> -					      conf->nr_queued > 0),
> +					    stop_waiting_barrier(conf),
>   					    conf->resync_lock);
> +			conf->nr_waiting--;
>   		}
> -		conf->nr_waiting--;
>   		if (!conf->nr_waiting)
>   			wake_up(&conf->wait_barrier);
>   	}

Acked-by: Paul Menzel <pmenzel@molgen.mpg.de>


Kind regards,

Paul

  reply	other threads:[~2022-09-14  6:36 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-14  1:49 [PATCH v2 0/4] md/raid10: reduce lock contention for io Yu Kuai
2022-09-14  1:49 ` [PATCH v2 1/4] md/raid10: cleanup wait_barrier() Yu Kuai
2022-09-14  6:36   ` Paul Menzel [this message]
2022-09-14 10:28     ` Yu Kuai
2022-09-14 16:16   ` Logan Gunthorpe
2022-09-15  7:21     ` Yu Kuai
2022-09-15  9:12       ` Paul Menzel
2022-09-14  1:49 ` [PATCH v2 2/4] md/raid10: prevent unnecessary calls to wake_up() in fast path Yu Kuai
2022-09-14 10:21   ` Yu Kuai
2022-09-14  1:49 ` [PATCH v2 3/4] md/raid10: fix improper BUG_ON() in raise_barrier() Yu Kuai
2022-09-14  1:49 ` [PATCH v2 4/4] md/raid10: convert resync_lock to use seqlock Yu Kuai
2022-09-14 10:26   ` Yu Kuai

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0b67df9e-7f64-e710-5928-2098ed8d0f2d@molgen.mpg.de \
    --to=pmenzel@molgen.mpg.de \
    --cc=guoqing.jiang@linux.dev \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-raid@vger.kernel.org \
    --cc=logang@deltatee.com \
    --cc=song@kernel.org \
    --cc=yi.zhang@huawei.com \
    --cc=yukuai1@huaweicloud.com \
    --cc=yukuai3@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox