public inbox for [email protected]
 help / color / mirror / Atom feed
From: John Garry <[email protected]>
To: Christoph Hellwig <[email protected]>, Hannes Reinecke <[email protected]>
Cc: [email protected], [email protected], [email protected],
	[email protected], [email protected],
	[email protected], [email protected], [email protected],
	[email protected], [email protected], [email protected],
	[email protected], [email protected],
	[email protected], [email protected], [email protected],
	[email protected], [email protected],
	[email protected], [email protected],
	[email protected], [email protected],
	[email protected], [email protected],
	Himanshu Madhani <[email protected]>
Subject: Re: [PATCH v7 4/9] block: Add core atomic write support
Date: Wed, 5 Jun 2024 12:21:51 +0100	[thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>

On 05/06/2024 09:32, Christoph Hellwig wrote:
> On Mon, Jun 03, 2024 at 02:29:26PM +0100, John Garry wrote:
>> I think that some of the logic could be re-used.
>> rq_straddles_atomic_write_boundary() is checked in merging of reqs/bios (to
>> see if the resultant req straddles a boundary).
>>
>> So instead of saying: "will the resultant req straddle a boundary",
>> re-using path like blk_rq_get_max_sectors() -> blk_chunk_sectors_left(), we
>> check "is there space within the boundary limit to add this req/bio". We
>> need to take care of front and back merges, though.
> 
> Yes, we've used the trick to pass in the relevant limit in explicitly
> to reuse infrastructure in other places, e.g. max_hw_sectors vs
> max_zone_append_sectors for adding to a bio while respecting hardware
> limits.
> 

I assume that you are talking about something like 
queue_limits_max_zone_append_sectors().

Anyway, below is the prep patch I was considering for this re-use. It's 
just renaming any infrastructure for "chunk_sectors" to generic 
"boundary_sectors".

------>8-------

The purpose of the chunk_sectors limit is to ensure that a mergeable 
request fits within the boundary of the chunck_sector value.

Such a feature will be useful for other request_queue boundary limits, 
so generalize the chunk_sectors merge code.

This idea was proposed by Hannes Reinecke.

Signed-off-by: John Garry <[email protected]>

diff --git a/block/blk-merge.c b/block/blk-merge.c
index 8957e08e020c..6574c8b64ecc 100644
--- a/block/blk-merge.c
+++ b/block/blk-merge.c
@@ -168,11 +168,12 @@ static inline unsigned get_max_io_size(struct bio 
*bio,
  	unsigned pbs = lim->physical_block_size >> SECTOR_SHIFT;
  	unsigned lbs = lim->logical_block_size >> SECTOR_SHIFT;
  	unsigned max_sectors = lim->max_sectors, start, end;
+	unsigned int boundary_sectors = lim->chunk_sectors;

-	if (lim->chunk_sectors) {
+	if (boundary_sectors) {
  		max_sectors = min(max_sectors,
-			blk_chunk_sectors_left(bio->bi_iter.bi_sector,
-					       lim->chunk_sectors));
+			blk_boundary_sectors_left(bio->bi_iter.bi_sector,
+					      boundary_sectors));
  	}

  	start = bio->bi_iter.bi_sector & (pbs - 1);
@@ -588,19 +589,19 @@ static inline unsigned int 
blk_rq_get_max_sectors(struct request *rq,
  						  sector_t offset)
  {
  	struct request_queue *q = rq->q;
-	unsigned int max_sectors;
+	unsigned int max_sectors, boundary_sectors = q->limits.chunk_sectors;

  	if (blk_rq_is_passthrough(rq))
  		return q->limits.max_hw_sectors;

  	max_sectors = blk_queue_get_max_sectors(rq);

-	if (!q->limits.chunk_sectors ||
+	if (!boundary_sectors ||
  	    req_op(rq) == REQ_OP_DISCARD ||
  	    req_op(rq) == REQ_OP_SECURE_ERASE)
  		return max_sectors;
  	return min(max_sectors,
-		   blk_chunk_sectors_left(offset, q->limits.chunk_sectors));
+		   blk_boundary_sectors_left(offset, boundary_sectors));
  }

  static inline int ll_new_hw_segment(struct request *req, struct bio *bio,
diff --git a/drivers/md/dm.c b/drivers/md/dm.c
index 13037d6a6f62..b648253c2300 100644
--- a/drivers/md/dm.c
+++ b/drivers/md/dm.c
@@ -1188,7 +1188,7 @@ static sector_t __max_io_len(struct dm_target *ti, 
sector_t sector,
  		return len;
  	return min_t(sector_t, len,
  		min(max_sectors ? : queue_max_sectors(ti->table->md->queue),
-		    blk_chunk_sectors_left(target_offset, max_granularity)));
+		    blk_boundary_sectors_left(target_offset, max_granularity)));
  }

  static inline sector_t max_io_len(struct dm_target *ti, sector_t sector)
diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index ac8e0cb2353a..7657698b47f4 100644
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@ -866,14 +866,14 @@ static inline bool bio_straddles_zones(struct bio 
*bio)
  }

  /*
- * Return how much of the chunk is left to be used for I/O at a given 
offset.
+ * Return how much within the boundary is left to be used for I/O at a 
given offset.
   */
-static inline unsigned int blk_chunk_sectors_left(sector_t offset,
-		unsigned int chunk_sectors)
+static inline unsigned int blk_boundary_sectors_left(sector_t offset,
+		unsigned int boundary_sectors)
  {
-	if (unlikely(!is_power_of_2(chunk_sectors)))
-		return chunk_sectors - sector_div(offset, chunk_sectors);
-	return chunk_sectors - (offset & (chunk_sectors - 1));
+	if (unlikely(!is_power_of_2(boundary_sectors)))
+		return boundary_sectors - sector_div(offset, boundary_sectors);
+	return boundary_sectors - (offset & (boundary_sectors - 1));
  }

  /**
-- 
2.31.1






  reply	other threads:[~2024-06-05 11:22 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-02 14:09 [PATCH v7 0/9] block atomic writes John Garry
2024-06-02 14:09 ` [PATCH v7 1/9] block: Pass blk_queue_get_max_sectors() a request pointer John Garry
2024-06-02 14:09 ` [PATCH v7 2/9] fs: Initial atomic write support John Garry
2024-06-05  8:30   ` Christoph Hellwig
2024-06-05 10:48     ` John Garry
2024-06-06  5:41       ` Christoph Hellwig
2024-06-06  6:38         ` John Garry
2024-06-02 14:09 ` [PATCH v7 3/9] fs: Add initial atomic write support info to statx John Garry
2024-06-02 14:09 ` [PATCH v7 4/9] block: Add core atomic write support John Garry
2024-06-03  9:26   ` Hannes Reinecke
2024-06-03 11:38     ` John Garry
2024-06-03 12:31       ` Hannes Reinecke
2024-06-03 13:29         ` John Garry
2024-06-05  8:32           ` Christoph Hellwig
2024-06-05 11:21             ` John Garry [this message]
2024-06-06  5:44               ` Christoph Hellwig
2024-06-05  8:31         ` Christoph Hellwig
2024-06-02 14:09 ` [PATCH v7 5/9] block: Add atomic write support for statx John Garry
2024-06-02 14:09 ` [PATCH v7 6/9] block: Add fops atomic write support John Garry
2024-06-02 14:09 ` [PATCH v7 7/9] scsi: sd: Atomic " John Garry
2024-06-02 14:09 ` [PATCH v7 8/9] scsi: scsi_debug: " John Garry
2024-06-02 14:09 ` [PATCH v7 9/9] nvme: " John Garry
2024-06-07  6:16 ` [PATCH v7 0/9] block atomic writes John Garry

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 \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    /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