From: keith.busch@intel.com (Keith Busch)
Subject: [PATCH rfc 0/6] convert nvme pci to use irq-poll service
Date: Wed, 5 Oct 2016 17:47:31 -0400 [thread overview]
Message-ID: <20161005214730.GA1053@localhost.localdomain> (raw)
In-Reply-To: <1475660534-16681-1-git-send-email-sagi@grimberg.me>
On Wed, Oct 05, 2016@12:42:08PM +0300, Sagi Grimberg wrote:
> I ran some tests with this and it seemed to work pretty well with
> my low-end nvme devices. One phenomenon I've encountered was that
> for single core long queue-depth'ed randread workload I saw around
> ~8-10% iops decrease. However when running multi-core IO I didn't
> see any noticeable performance degradation. non-polling Canonical
> randread latency doesn't seem to be affected as well. And also
> polling mode IO is not affected as expected.
>
> So in addition for review and feedback, this is a call for testing
> and benchmarking as this touches the critical data path.
Hi Sagi,
Just reconfirming your findings with another data point, I ran this on
controllers with 3D Xpoint media, and single depth 4k random read latency
increased almost 7%. I'll try see if there's anything else we can do to
bring that in.
next prev parent reply other threads:[~2016-10-05 21:47 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-05 9:42 [PATCH rfc 0/6] convert nvme pci to use irq-poll service Sagi Grimberg
2016-10-05 9:42 ` [PATCH rfc 1/6] nvme-pci: Split __nvme_process_cq to poll and handle Sagi Grimberg
2016-10-05 13:21 ` Johannes Thumshirn
2016-10-05 16:52 ` Sagi Grimberg
2016-10-05 19:49 ` Jon Derrick
2016-10-10 7:25 ` Johannes Thumshirn
2016-10-05 9:42 ` [PATCH rfc 2/6] nvme-pci: Add budget to __nvme_process_cq Sagi Grimberg
2016-10-05 13:26 ` Johannes Thumshirn
2016-10-05 9:42 ` [PATCH rfc 3/6] nvme-pci: Use irq-poll for completion processing Sagi Grimberg
2016-10-05 13:40 ` Johannes Thumshirn
2016-10-05 16:57 ` Sagi Grimberg
2016-10-10 7:47 ` Johannes Thumshirn
2016-10-05 9:42 ` [PATCH rfc 4/6] nvme: don't consume cq in queue_rq Sagi Grimberg
2016-10-05 13:42 ` Johannes Thumshirn
2016-10-05 9:42 ` [PATCH rfc 5/6] nvme-pci: open-code polling logic in nvme_poll Sagi Grimberg
2016-10-05 13:52 ` Johannes Thumshirn
2016-10-05 17:02 ` Sagi Grimberg
2016-10-10 7:49 ` Johannes Thumshirn
2016-10-05 9:42 ` [PATCH rfc 6/6] nvme-pci: Get rid of threaded interrupts Sagi Grimberg
2016-10-05 13:47 ` Johannes Thumshirn
2016-10-05 21:47 ` Keith Busch [this message]
2016-10-05 21:55 ` [PATCH rfc 0/6] convert nvme pci to use irq-poll service Sagi Grimberg
2016-10-05 22:49 ` Keith Busch
2016-10-05 22:48 ` Sagi Grimberg
2016-10-27 10:09 ` Johannes Thumshirn
2016-10-27 10:31 ` Sagi Grimberg
2016-10-27 10:58 ` Johannes Thumshirn
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=20161005214730.GA1053@localhost.localdomain \
--to=keith.busch@intel.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.