From: Minwoo Im <minwoo.im.dev@gmail.com>
To: Weiping Zhang <zwp10758@gmail.com>
Cc: Weiping Zhang <zhangweiping@didiglobal.com>,
Jens Axboe <axboe@kernel.dk>, Tejun Heo <tj@kernel.org>,
Christoph Hellwig <hch@lst.de>,
Bart Van Assche <bvanassche@acm.org>,
keith.busch@intel.com, linux-block@vger.kernel.org,
cgroups@vger.kernel.org, linux-nvme@lists.infradead.org,
Minwoo Im <minwoo.im.dev@gmail.com>
Subject: Re: [PATCH v3 3/5] nvme-pci: rename module parameter write_queues to read_queues
Date: Thu, 27 Jun 2019 05:27:06 +0900 [thread overview]
Message-ID: <20190626202706.GC4934@minwooim-desktop> (raw)
In-Reply-To: <CAA70yB5arvfaUsktN-cvd0yHpRi+FwFjL4r5_jTRWM8+rBVdnA@mail.gmail.com>
On 19-06-25 22:48:57, Weiping Zhang wrote:
> Minwoo Im <minwoo.im.dev@gmail.com> 于2019年6月25日周二 上午6:00写道:
> >
> > On 19-06-24 22:29:19, Weiping Zhang wrote:
> > > Now nvme support three type hardware queues, read, poll and default,
> > > this patch rename write_queues to read_queues to set the number of
> > > read queues more explicitly. This patch alos is prepared for nvme
> > > support WRR(weighted round robin) that we can get the number of
> > > each queue type easily.
> > >
> > > Signed-off-by: Weiping Zhang <zhangweiping@didiglobal.com>
> >
> > Hello, Weiping.
> >
> > Thanks for making this patch as a separated one. Actually I'd like to
> > hear about if the origin purpose of this param can be changed or not.
> >
> > I can see a log from Jens when it gets added her:
> > Commit 3b6592f70ad7("nvme: utilize two queue maps, one for reads and
> > one for writes")
> > It says:
> > """
> > NVMe does round-robin between queues by default, which means that
> > sharing a queue map for both reads and writes can be problematic
> > in terms of read servicing. It's much easier to flood the queue
> > with writes and reduce the read servicing.
> > """
> >
> > So, I'd like to hear what other people think about this patch :)
> >
>
> This patch does not change its original behavior, if we set read_queue
> greater than 0, the read and write request will use different tagset map,
> so they will use different hardware queue.
Yes, that's why I want to hear some comments for this change from other
people. I'm not against this change, though.
WARNING: multiple messages have this Message-ID (diff)
From: minwoo.im.dev@gmail.com (Minwoo Im)
Subject: [PATCH v3 3/5] nvme-pci: rename module parameter write_queues to read_queues
Date: Thu, 27 Jun 2019 05:27:06 +0900 [thread overview]
Message-ID: <20190626202706.GC4934@minwooim-desktop> (raw)
In-Reply-To: <CAA70yB5arvfaUsktN-cvd0yHpRi+FwFjL4r5_jTRWM8+rBVdnA@mail.gmail.com>
On 19-06-25 22:48:57, Weiping Zhang wrote:
> Minwoo Im <minwoo.im.dev at gmail.com> ?2019?6?25??? ??6:00???
> >
> > On 19-06-24 22:29:19, Weiping Zhang wrote:
> > > Now nvme support three type hardware queues, read, poll and default,
> > > this patch rename write_queues to read_queues to set the number of
> > > read queues more explicitly. This patch alos is prepared for nvme
> > > support WRR(weighted round robin) that we can get the number of
> > > each queue type easily.
> > >
> > > Signed-off-by: Weiping Zhang <zhangweiping at didiglobal.com>
> >
> > Hello, Weiping.
> >
> > Thanks for making this patch as a separated one. Actually I'd like to
> > hear about if the origin purpose of this param can be changed or not.
> >
> > I can see a log from Jens when it gets added her:
> > Commit 3b6592f70ad7("nvme: utilize two queue maps, one for reads and
> > one for writes")
> > It says:
> > """
> > NVMe does round-robin between queues by default, which means that
> > sharing a queue map for both reads and writes can be problematic
> > in terms of read servicing. It's much easier to flood the queue
> > with writes and reduce the read servicing.
> > """
> >
> > So, I'd like to hear what other people think about this patch :)
> >
>
> This patch does not change its original behavior, if we set read_queue
> greater than 0, the read and write request will use different tagset map,
> so they will use different hardware queue.
Yes, that's why I want to hear some comments for this change from other
people. I'm not against this change, though.
next prev parent reply other threads:[~2019-06-26 20:27 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <cover.1561385989.git.zhangweiping@didiglobal.com>
2019-06-24 14:28 ` [PATCH v3 1/5] block: add weighted round robin for blkcgroup Weiping Zhang
2019-06-24 14:28 ` Weiping Zhang
2019-07-18 13:59 ` Tejun Heo
2019-07-18 13:59 ` Tejun Heo
2019-07-23 14:29 ` Weiping Zhang
2019-07-23 14:29 ` Weiping Zhang
2019-06-24 14:29 ` [PATCH v3 2/5] nvme: add get_ams for nvme_ctrl_ops Weiping Zhang
2019-06-24 14:29 ` Weiping Zhang
2019-06-24 20:12 ` Minwoo Im
2019-06-24 20:12 ` Minwoo Im
2019-06-25 14:46 ` Weiping Zhang
2019-06-25 14:46 ` Weiping Zhang
2019-06-24 14:29 ` [PATCH v3 3/5] nvme-pci: rename module parameter write_queues to read_queues Weiping Zhang
2019-06-24 14:29 ` Weiping Zhang
2019-06-24 20:04 ` Minwoo Im
2019-06-24 20:04 ` Minwoo Im
2019-06-25 14:48 ` Weiping Zhang
2019-06-25 14:48 ` Weiping Zhang
2019-06-26 20:27 ` Minwoo Im [this message]
2019-06-26 20:27 ` Minwoo Im
2019-07-14 11:36 ` Minwoo Im
2019-06-24 14:29 ` [PATCH v3 4/5] genirq/affinity: allow driver's discontigous affinity set Weiping Zhang
2019-06-24 14:29 ` Weiping Zhang
2019-06-24 14:29 ` Weiping Zhang
2019-06-24 15:42 ` Thomas Gleixner
2019-06-24 15:42 ` Thomas Gleixner
2019-06-25 2:14 ` Ming Lei
2019-06-25 2:14 ` Ming Lei
2019-06-25 6:13 ` Thomas Gleixner
2019-06-25 6:13 ` Thomas Gleixner
2019-06-25 14:55 ` Weiping Zhang
2019-06-25 14:55 ` Weiping Zhang
2019-06-24 14:29 ` [PATCH v3 5/5] nvme: add support weighted round robin queue Weiping Zhang
2019-06-24 14:29 ` Weiping Zhang
2019-06-24 20:21 ` Minwoo Im
2019-06-24 20:21 ` Minwoo Im
2019-06-25 15:06 ` Weiping Zhang
2019-06-25 15:06 ` Weiping Zhang
2019-06-27 10:37 ` Minwoo Im
2019-06-27 10:37 ` Minwoo Im
2019-06-27 11:03 ` Christoph Hellwig
2019-06-27 11:03 ` Christoph Hellwig
2019-06-28 15:57 ` Weiping Zhang
2019-06-28 15:57 ` Weiping Zhang
2019-07-10 14:20 ` Weiping Zhang
2019-07-10 14:20 ` Weiping Zhang
2019-07-29 10:22 ` Weiping Zhang
2019-07-29 10:22 ` Weiping Zhang
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=20190626202706.GC4934@minwooim-desktop \
--to=minwoo.im.dev@gmail.com \
--cc=axboe@kernel.dk \
--cc=bvanassche@acm.org \
--cc=cgroups@vger.kernel.org \
--cc=hch@lst.de \
--cc=keith.busch@intel.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=tj@kernel.org \
--cc=zhangweiping@didiglobal.com \
--cc=zwp10758@gmail.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 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.