public inbox for linux-block@vger.kernel.org
 help / color / mirror / Atom feed
From: Nilay Shroff <nilay@linux.ibm.com>
To: linux-block@vger.kernel.org
Cc: john.g.garry@oracle.com, hch@lst.de, martin.petersen@oracle.com,
	axboe@kernel.dk, ojaswin@linux.ibm.com, gjoyce@ibm.com
Subject: [PATCH] block: fix atomic write limits for stacked devices
Date: Tue,  3 Jun 2025 16:57:55 +0530	[thread overview]
Message-ID: <20250603112804.1917861-1-nilay@linux.ibm.com> (raw)

The current logic applies the bottom device's atomic write limits to
the stacked (top) device only if the top device does not support chunk
sectors. However, this approach is too restrictive.

We should also propagate the bottom device's atomic write limits to the
stacked device if atomic_write_hw_unit_{min,max} of the bottom device
are aligned with the top device's chunk size (io_min). Failing to do so
may unnecessarily reduce the stacked device's atomic write limits to
values much smaller than what the hardware can actually support.

For example, on an NVMe disk with the following controller capability:
$ nvme id-ctrl /dev/nvme1  | grep awupf
awupf     : 63

Without the patch applied,

The bottom device (nvme1c1n1) atomic queue limits:
$ /sys/block/nvme1c1n1/queue/atomic_write_boundary_bytes:0
$ /sys/block/nvme1c1n1/queue/atomic_write_max_bytes:262144
$ /sys/block/nvme1c1n1/queue/atomic_write_unit_max_bytes:262144
$ /sys/block/nvme1c1n1/queue/atomic_write_unit_min_bytes:4096

The top device (nvme1n1) atomic queue limits:
$ /sys/block/nvme1n1/queue/atomic_write_boundary_bytes:0
$ /sys/block/nvme1n1/queue/atomic_write_max_bytes:4096
$ /sys/block/nvme1n1/queue/atomic_write_unit_max_bytes:4096
$ /sys/block/nvme1n1/queue/atomic_write_unit_min_bytes:4096

With this patch applied,

The top device (nvme1n1) atomic queue limits:
/sys/block/nvme1n1/queue/atomic_write_boundary_bytes:0
/sys/block/nvme1n1/queue/atomic_write_max_bytes:262144
/sys/block/nvme1n1/queue/atomic_write_unit_max_bytes:262144
/sys/block/nvme1n1/queue/atomic_write_unit_min_bytes:4096

This change ensures that the stacked device retains optimal atomic write
capability when alignment permits, improving overall performance and
correctness.

Reported-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>
Fixes: d7f36dc446e8 ("block: Support atomic writes limits for stacked devices")
Signed-off-by: Nilay Shroff <nilay@linux.ibm.com>
---
 block/blk-settings.c | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/block/blk-settings.c b/block/blk-settings.c
index a000daafbfb4..35c1354dd5ae 100644
--- a/block/blk-settings.c
+++ b/block/blk-settings.c
@@ -598,8 +598,14 @@ static bool blk_stack_atomic_writes_head(struct queue_limits *t,
 	    !blk_stack_atomic_writes_boundary_head(t, b))
 		return false;
 
-	if (t->io_min <= SECTOR_SIZE) {
-		/* No chunk sectors, so use bottom device values directly */
+	if (t->io_min <= SECTOR_SIZE ||
+	    (!(t->atomic_write_hw_unit_max % t->io_min) &&
+	     !(t->atomic_write_hw_unit_min % t->io_min))) {
+		/*
+		 * If there are no chunk sectors, or if b->atomic_write_hw_unit
+		 * _{min, max} are aligned to the chunk size (t->io_min), then
+		 * use the bottom device's values directly.
+		 */
 		t->atomic_write_hw_unit_max = b->atomic_write_hw_unit_max;
 		t->atomic_write_hw_unit_min = b->atomic_write_hw_unit_min;
 		t->atomic_write_hw_max = b->atomic_write_hw_max;
-- 
2.49.0


             reply	other threads:[~2025-06-03 11:28 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-03 11:27 Nilay Shroff [this message]
2025-06-03 12:17 ` [PATCH] block: fix atomic write limits for stacked devices John Garry
2025-06-03 15:16   ` Nilay Shroff
2025-06-04  7:29     ` John Garry
2025-06-04 15:09       ` Nilay Shroff
2025-06-05  9:01         ` John Garry
2025-06-05  9:50           ` Nilay Shroff

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=20250603112804.1917861-1-nilay@linux.ibm.com \
    --to=nilay@linux.ibm.com \
    --cc=axboe@kernel.dk \
    --cc=gjoyce@ibm.com \
    --cc=hch@lst.de \
    --cc=john.g.garry@oracle.com \
    --cc=linux-block@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=ojaswin@linux.ibm.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