public inbox for linux-block@vger.kernel.org
 help / color / mirror / Atom feed
From: Shaohua Li <shli@kernel.org>
To: Goldwyn Rodrigues <rgoldwyn@suse.de>
Cc: linux-block@vger.kernel.org, hch@infradead.org, jack@suse.cz,
	linux-raid@vger.kernel.org, dm-devel@redhat.com,
	Goldwyn Rodrigues <rgoldwyn@suse.com>
Subject: Re: [PATCH 3/9] md: raid1 nowait support
Date: Tue, 8 Aug 2017 13:39:07 -0700	[thread overview]
Message-ID: <20170808203907.obfzlkqe4zboipva@kernel.org> (raw)
In-Reply-To: <20170726235806.12148-4-rgoldwyn@suse.de>

On Wed, Jul 26, 2017 at 06:58:00PM -0500, Goldwyn Rodrigues wrote:
> From: Goldwyn Rodrigues <rgoldwyn@suse.com>
> 
> The RAID1 driver would bail with EAGAIN in case of:
>  + I/O has to wait for a barrier
>  + array is frozen
>  + Area is suspended
>  + There are too many pending I/O that it will be queued.
> 
> To facilitate error for wait barriers, wait_barrier() is
> returning bool. True in case if there was a wait (or is not
> required). False in case a wait was required, but was not performed.
> 
> Signed-off-by: Goldwyn Rodrigues <rgoldwyn@suse.com>
> ---
>  drivers/md/raid1.c | 74 +++++++++++++++++++++++++++++++++++++++++-------------
>  1 file changed, 57 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/md/raid1.c b/drivers/md/raid1.c
> index 3febfc8391fb..66ca4288e3e8 100644
> --- a/drivers/md/raid1.c
> +++ b/drivers/md/raid1.c
> @@ -903,8 +903,9 @@ static void lower_barrier(struct r1conf *conf, sector_t sector_nr)
>  	wake_up(&conf->wait_barrier);
>  }
>  
> -static void _wait_barrier(struct r1conf *conf, int idx)
> +static bool _wait_barrier(struct r1conf *conf, int idx, bool nowait)
>  {
> +	bool ret = true;
>  	/*
>  	 * We need to increase conf->nr_pending[idx] very early here,
>  	 * then raise_barrier() can be blocked when it waits for
> @@ -935,7 +936,7 @@ static void _wait_barrier(struct r1conf *conf, int idx)
>  	 */
>  	if (!READ_ONCE(conf->array_frozen) &&
>  	    !atomic_read(&conf->barrier[idx]))
> -		return;
> +		return ret;
>  
>  	/*
>  	 * After holding conf->resync_lock, conf->nr_pending[idx]
> @@ -953,18 +954,26 @@ static void _wait_barrier(struct r1conf *conf, int idx)
>  	 */
>  	wake_up(&conf->wait_barrier);
>  	/* Wait for the barrier in same barrier unit bucket to drop. */
> -	wait_event_lock_irq(conf->wait_barrier,
> -			    !conf->array_frozen &&
> -			     !atomic_read(&conf->barrier[idx]),
> -			    conf->resync_lock);
> +	if (conf->array_frozen || atomic_read(&conf->barrier[idx])) {
> +		if (nowait)
> +			ret = false;

In this case, we nr_pending shouldn't be increased

> +		else
> +			wait_event_lock_irq(conf->wait_barrier,
> +					!conf->array_frozen &&
> +					!atomic_read(&conf->barrier[idx]),
> +					conf->resync_lock);
> +	}
>  	atomic_inc(&conf->nr_pending[idx]);
>  	atomic_dec(&conf->nr_waiting[idx]);
>  	spin_unlock_irq(&conf->resync_lock);
> +	return ret;
>  }
>  
> -static void wait_read_barrier(struct r1conf *conf, sector_t sector_nr)
> +static bool wait_read_barrier(struct r1conf *conf, sector_t sector_nr,
> +		bool nowait)
>  {
>  	int idx = sector_to_idx(sector_nr);
> +	bool ret = true;
>  
>  	/*
>  	 * Very similar to _wait_barrier(). The difference is, for read
> @@ -976,7 +985,7 @@ static void wait_read_barrier(struct r1conf *conf, sector_t sector_nr)
>  	atomic_inc(&conf->nr_pending[idx]);
>  
>  	if (!READ_ONCE(conf->array_frozen))
> -		return;
> +		return ret;
>  
>  	spin_lock_irq(&conf->resync_lock);
>  	atomic_inc(&conf->nr_waiting[idx]);
> @@ -987,19 +996,28 @@ static void wait_read_barrier(struct r1conf *conf, sector_t sector_nr)
>  	 */
>  	wake_up(&conf->wait_barrier);
>  	/* Wait for array to be unfrozen */
> -	wait_event_lock_irq(conf->wait_barrier,
> -			    !conf->array_frozen,
> -			    conf->resync_lock);
> +	if (conf->array_frozen) {
> +		/* If nowait flag is set, return false to
> +		 * show we did not wait
> +		 */
> +		if (nowait)
> +			ret = false;

ditto
> +		else
> +			wait_event_lock_irq(conf->wait_barrier,
> +					!conf->array_frozen,
> +					conf->resync_lock);
> +	}
>  	atomic_inc(&conf->nr_pending[idx]);
>  	atomic_dec(&conf->nr_waiting[idx]);
>  	spin_unlock_irq(&conf->resync_lock);
> +	return ret;
>  }
>  
> -static void wait_barrier(struct r1conf *conf, sector_t sector_nr)
> +static bool wait_barrier(struct r1conf *conf, sector_t sector_nr, bool nowait)
>  {
>  	int idx = sector_to_idx(sector_nr);
>  
> -	_wait_barrier(conf, idx);
> +	return _wait_barrier(conf, idx, nowait);
>  }
>  
>  static void wait_all_barriers(struct r1conf *conf)
> @@ -1007,7 +1025,7 @@ static void wait_all_barriers(struct r1conf *conf)
>  	int idx;
>  
>  	for (idx = 0; idx < BARRIER_BUCKETS_NR; idx++)
> -		_wait_barrier(conf, idx);
> +		_wait_barrier(conf, idx, false);
>  }
>  
>  static void _allow_barrier(struct r1conf *conf, int idx)
> @@ -1223,7 +1241,11 @@ static void raid1_read_request(struct mddev *mddev, struct bio *bio,
>  	 * Still need barrier for READ in case that whole
>  	 * array is frozen.
>  	 */
> -	wait_read_barrier(conf, bio->bi_iter.bi_sector);
> +	if (!wait_read_barrier(conf, bio->bi_iter.bi_sector,
> +				bio->bi_opf & REQ_NOWAIT)) {
> +		bio_wouldblock_error(bio);
> +		return;
> +	}
>  
>  	if (!r1_bio)
>  		r1_bio = alloc_r1bio(mddev, bio);
> @@ -1333,6 +1355,11 @@ static void raid1_write_request(struct mddev *mddev, struct bio *bio,
>  		 * an interruptible wait.
>  		 */
>  		DEFINE_WAIT(w);
> +		if (bio->bi_opf & REQ_NOWAIT) {
> +			bio_wouldblock_error(bio);
> +			return;
> +		}
> +
>  		for (;;) {
>  			sigset_t full, old;
>  			prepare_to_wait(&conf->wait_barrier,
> @@ -1351,7 +1378,11 @@ static void raid1_write_request(struct mddev *mddev, struct bio *bio,
>  		}
>  		finish_wait(&conf->wait_barrier, &w);
>  	}
> -	wait_barrier(conf, bio->bi_iter.bi_sector);
> +	if (!wait_barrier(conf, bio->bi_iter.bi_sector,
> +				bio->bi_opf & REQ_NOWAIT)) {
> +		bio_wouldblock_error(bio);
> +		return;
> +	}
>  
>  	r1_bio = alloc_r1bio(mddev, bio);
>  	r1_bio->sectors = max_write_sectors;
> @@ -1359,6 +1390,10 @@ static void raid1_write_request(struct mddev *mddev, struct bio *bio,
>  	if (conf->pending_count >= max_queued_requests) {
>  		md_wakeup_thread(mddev->thread);
>  		raid1_log(mddev, "wait queued");
> +		if (bio->bi_opf & REQ_NOWAIT) {
> +			bio_wouldblock_error(bio);
> +			return;
> +		}
>  		wait_event(conf->wait_barrier,
>  			   conf->pending_count < max_queued_requests);
>  	}
> @@ -1442,6 +1477,11 @@ static void raid1_write_request(struct mddev *mddev, struct bio *bio,
>  		/* Wait for this device to become unblocked */
>  		int j;
>  
> +		if (bio->bi_opf & REQ_NOWAIT) {
> +			bio_wouldblock_error(bio);
> +			return;
> +		}
> +
>  		for (j = 0; j < i; j++)
>  			if (r1_bio->bios[j])
>  				rdev_dec_pending(conf->mirrors[j].rdev, mddev);
> @@ -1449,7 +1489,7 @@ static void raid1_write_request(struct mddev *mddev, struct bio *bio,
>  		allow_barrier(conf, bio->bi_iter.bi_sector);
>  		raid1_log(mddev, "wait rdev %d blocked", blocked_rdev->raid_disk);
>  		md_wait_for_blocked_rdev(blocked_rdev, mddev);
> -		wait_barrier(conf, bio->bi_iter.bi_sector);
> +		wait_barrier(conf, bio->bi_iter.bi_sector, false);

There are other cases we could block, for example, md_wait_for_blocked_rdev
here. Is the goal just avoid block for normal situations?

>  		goto retry_write;
>  	}
>  
> -- 
> 2.12.3
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2017-08-08 20:39 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-26 23:57 [PATCH 0/9] Nowait feature for stacked block devices Goldwyn Rodrigues
2017-07-26 23:57 ` [PATCH 1/9] QUEUE_FLAG_NOWAIT to indicate device supports nowait Goldwyn Rodrigues
2017-08-08 20:32   ` Shaohua Li
2017-08-08 20:36     ` Jens Axboe
2017-08-10  2:18       ` Jens Axboe
2017-08-10 11:38         ` Goldwyn Rodrigues
2017-08-10 14:14           ` Jens Axboe
2017-08-10 17:15             ` Goldwyn Rodrigues
2017-08-10 17:17               ` Jens Axboe
2017-08-09 11:44     ` Goldwyn Rodrigues
2017-08-09 15:02       ` Shaohua Li
2017-08-09 15:35         ` Goldwyn Rodrigues
2017-08-09 20:21           ` Shaohua Li
2017-08-09 22:16             ` Goldwyn Rodrigues
2017-08-10  1:17               ` Shaohua Li
2017-08-10  2:07                 ` Goldwyn Rodrigues
2017-08-10  2:17                   ` Jens Axboe
2017-08-10 11:49                     ` Goldwyn Rodrigues
2017-08-10 14:23                       ` Jens Axboe
2017-08-10 14:25                       ` Jan Kara
2017-08-10 14:28                         ` Jens Axboe
2017-08-10 17:15                           ` Goldwyn Rodrigues
2017-08-10 17:20                             ` Jens Axboe
2017-07-26 23:57 ` [PATCH 2/9] md: Add nowait support to md Goldwyn Rodrigues
2017-08-08 20:34   ` Shaohua Li
2017-07-26 23:58 ` [PATCH 3/9] md: raid1 nowait support Goldwyn Rodrigues
2017-08-08 20:39   ` Shaohua Li [this message]
2017-08-09 11:45     ` Goldwyn Rodrigues
2017-07-26 23:58 ` [PATCH 4/9] md: raid5 " Goldwyn Rodrigues
2017-08-08 20:43   ` Shaohua Li
2017-08-09 11:45     ` Goldwyn Rodrigues
2017-07-26 23:58 ` [PATCH 5/9] md: raid10 " Goldwyn Rodrigues
2017-08-08 20:40   ` Shaohua Li
2017-07-26 23:58 ` [PATCH 6/9] dm: add " Goldwyn Rodrigues
2017-07-26 23:58 ` [PATCH 7/9] dm: Add nowait support to raid1 Goldwyn Rodrigues
2017-07-26 23:58 ` [PATCH 8/9] dm: Add nowait support to dm-delay Goldwyn Rodrigues
2017-07-26 23:58 ` [PATCH 9/9] dm-mpath: Add nowait support Goldwyn Rodrigues
  -- strict thread matches above, loose matches on Subject: below --
2017-10-04 13:55 [PATCH v2 0/9] Nowait support for stacked block devices Goldwyn Rodrigues
2017-10-04 13:55 ` [PATCH 3/9] md: raid1 nowait support Goldwyn Rodrigues

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=20170808203907.obfzlkqe4zboipva@kernel.org \
    --to=shli@kernel.org \
    --cc=dm-devel@redhat.com \
    --cc=hch@infradead.org \
    --cc=jack@suse.cz \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-raid@vger.kernel.org \
    --cc=rgoldwyn@suse.com \
    --cc=rgoldwyn@suse.de \
    /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