From: Nilay Shroff <nilay@linux.ibm.com>
To: Keith Busch <kbusch@kernel.org>
Cc: linux-nvme@lists.infradead.org, hch@lst.de, sagi@grimberg.me,
axboe@fb.com, gjoyce@linux.ibm.com
Subject: Re: [PATCH RFC 0/1] Add visibility for native NVMe miltipath using debugfs
Date: Thu, 25 Jul 2024 11:50:33 +0530 [thread overview]
Message-ID: <ee820e6d-8667-4ba5-b8b2-b936a29f1a18@linux.ibm.com> (raw)
In-Reply-To: <ZqERmEICdLEvQ6aQ@kbusch-mbp>
On 7/24/24 20:07, Keith Busch wrote:
> On Mon, Jul 22, 2024 at 03:01:08PM +0530, Nilay Shroff wrote:
>> # cat /sys/kernel/debug/block/nvme1n1/multipath
>> io-policy: queue-depth
>> io-path:
>> --------
>> node path ctrl qdepth ana-state
>> 2 nvme1c1n1 nvme1 1328 optimized
>> 2 nvme1c3n1 nvme3 1324 optimized
>> 3 nvme1c1n1 nvme1 1328 optimized
>> 3 nvme1c3n1 nvme3 1324 optimized
>>
>> The above output was captured while I/O was running and accessing
>> namespace nvme1n1. From the above output, we see that iopolicy is set to
>> "queue-depth". When we have I/O workload running on numa node 2, accessing
>> namespace "nvme1n1", the I/O path nvme1c1n1/nvme1 has queue depth of 1328
>> and another I/O path nvme1c3n1/nvme3 has queue depth of 1324. Both paths
>> are optimized and seems that both paths are equally utilized for
>> forwarding I/O.
>
> You can get the outstanding queue-depth from iostats too, and that
> doesn't rely on queue-depth io policy. It does, however, require stats
> are enabled, but that's probably a more reasonable given than an io
> policy.
>
Yes correct, user could use iostat to find the queue-depth in real-time
when I/O workload is running.
>> The same could be said for workload running on numa
>> node 3.
>
> The output for all numa nodes will be the same regardless of which node
> a workload is running on (the accounting isn't per-node), so I'm not
> sure outputting qdepth again for each node is useful.
Agreed, so in that case we may only show the available I/O paths for
head disk node when I/O policy is set to "queue-depth". In this case,
we don't need to show paths per numa node as you suggested. And then
for each I/O path we can show the "qdepth" once.
IMO, though it's possible to find the queue-depth monitoring the iostat
output, it'd be convenient to have it readily available under one place
where we would add further visibility of multipathing.
Thanks,
--Nilay
next prev parent reply other threads:[~2024-07-25 6:20 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-22 9:31 [PATCH RFC 0/1] Add visibility for native NVMe miltipath using debugfs Nilay Shroff
2024-07-22 9:31 ` [PATCH RFC 1/1] nvme-multipath: Add debugfs entry for showing multipath info Nilay Shroff
2024-07-22 14:18 ` [PATCH RFC 0/1] Add visibility for native NVMe miltipath using debugfs Daniel Wagner
2024-07-23 5:18 ` Nilay Shroff
2024-07-23 7:40 ` Daniel Wagner
2024-07-24 13:41 ` Christoph Hellwig
2024-07-25 6:23 ` Nilay Shroff
2024-07-24 14:37 ` Keith Busch
2024-07-25 6:20 ` Nilay Shroff [this message]
2024-07-28 20:47 ` Sagi Grimberg
2024-07-29 4: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=ee820e6d-8667-4ba5-b8b2-b936a29f1a18@linux.ibm.com \
--to=nilay@linux.ibm.com \
--cc=axboe@fb.com \
--cc=gjoyce@linux.ibm.com \
--cc=hch@lst.de \
--cc=kbusch@kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=sagi@grimberg.me \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.