All of lore.kernel.org
 help / color / mirror / Atom feed
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


  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.