From: alan.adamson@oracle.com
To: Christoph Hellwig <hch@lst.de>
Cc: Keith Busch <kbusch@kernel.org>, Sagi Grimberg <sagi@grimberg.me>,
linux-nvme@lists.infradead.org, Yi Zhang <yi.zhang@redhat.com>,
John Garry <john.g.garry@oracle.com>
Subject: Re: fix atomic limits check
Date: Wed, 18 Jun 2025 09:07:42 -0700 [thread overview]
Message-ID: <9d0692b3-4d49-443f-b6f6-b13ec9a44f3b@oracle.com> (raw)
In-Reply-To: <20250618053213.GA28614@lst.de>
On 6/17/25 10:32 PM, Christoph Hellwig wrote:
> On Tue, Jun 17, 2025 at 10:40:35AM -0700, alan.adamson@oracle.com wrote:
>> I changed the config a bit:
>>
>> CTRL 0 - AWUN=31 AWUPF=15
>> CTRL 1 - AWUN=31 AWUPF=31
>> CTRL 2 - AWUN=15 AWUPF=7
>> CTRL 3 - AWUN=15 AWUPF=15
>> NS - NAWUN=31 NAWUPF=15
>> NS - NAWUN=127 NAWUPF=63
> I'm a bit confused what this config means. The NS lines here are
> multiple namespaces?
CTRL 0 - 2 - each has 1 namespace, none of which define namespace atomic
parameters.
CTRL 3 - has 2 namespaces both define namespace atomic parameters.
>
>> [root@localhost ~]# sh testxx.sh nvme0n3
> But this is all about the controller 0 above, which now has multiple
> namespaces?
>
>> + cat /sys/block/nvme0n3/queue/atomic_write_max_bytes
>> 8192
>> [root@localhost ~]# dmesg | grep -i awupf
>> [root@localhost ~]#
>>
>> AWUPF of 7 isn't consistent with an atomic_write_max_bytes of 8192.
> It is consistent with an (N)AWUPF=15, and it is namespace number 3. Are
> you testing controller 3 above or is the namespace shared between
> controller 0 and controller 3?
CTRL 2 (nvme0n3) has AWUPF=7 which means it supports a max atomic write
size of 4096b, but /sys/block/nvme0n3/queue/atomic_write_max_bytes is 8192b.
Alan
next prev parent reply other threads:[~2025-06-18 17:20 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-11 5:54 fix atomic limits check Christoph Hellwig
2025-06-11 5:54 ` [PATCH 1/2] nvme: refactor the atomic write unit detection Christoph Hellwig
2025-06-13 7:52 ` John Garry
2025-06-11 5:54 ` [PATCH 2/2] nvme: fix atomic write boundary validation Christoph Hellwig
2025-06-13 3:04 ` Yi Zhang
2025-06-13 8:03 ` John Garry
2025-06-16 5:31 ` Christoph Hellwig
2025-06-16 7:42 ` John Garry
2025-06-16 11:36 ` Christoph Hellwig
2025-06-16 10:19 ` John Garry
2025-06-16 11:37 ` Christoph Hellwig
2025-06-16 11:49 ` John Garry
2025-06-17 7:36 ` John Garry
2025-06-13 21:22 ` fix atomic limits check alan.adamson
2025-06-16 5:36 ` Christoph Hellwig
2025-06-17 17:40 ` alan.adamson
2025-06-18 5:32 ` Christoph Hellwig
2025-06-18 16:07 ` alan.adamson [this message]
[not found] ` <20250618171750.GA29321@lst.de>
2025-06-18 18:30 ` alan.adamson
2025-06-23 13:33 ` Christoph Hellwig
2025-06-23 17:24 ` alan.adamson
2025-06-24 13:10 ` Christoph Hellwig
2025-06-24 16:38 ` alan.adamson
2025-06-25 6:39 ` Christoph Hellwig
2025-06-17 4:56 ` Christoph Hellwig
2025-06-17 16:38 ` Luis Chamberlain
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=9d0692b3-4d49-443f-b6f6-b13ec9a44f3b@oracle.com \
--to=alan.adamson@oracle.com \
--cc=hch@lst.de \
--cc=john.g.garry@oracle.com \
--cc=kbusch@kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=sagi@grimberg.me \
--cc=yi.zhang@redhat.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;
as well as URLs for NNTP newsgroup(s).