From: Bart Van Assche <Bart.VanAssche@sandisk.com>
To: "jthumshirn@suse.de" <jthumshirn@suse.de>,
"lsf-pc@lists.linux-foundation.org"
<lsf-pc@lists.linux-foundation.org>,
"sagi@grimberg.me" <sagi@grimberg.me>
Cc: "hch@infradead.org" <hch@infradead.org>,
"keith.busch@intel.com" <keith.busch@intel.com>,
"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
"linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>,
"Linux-scsi@vger.kernel.org" <Linux-scsi@vger.kernel.org>
Subject: Re: [LSF/MM TOPIC][LSF/MM ATTEND] NAPI polling for block drivers
Date: Thu, 12 Jan 2017 19:13:17 +0000 [thread overview]
Message-ID: <1484248382.2720.9.camel@sandisk.com> (raw)
In-Reply-To: <ccb6cf4d-4810-47b2-015a-0202d784280a@grimberg.me>
On Thu, 2017-01-12 at 10:41 +0200, Sagi Grimberg wrote:
> First, when the nvme device fires an interrupt, the driver consumes
> the completion(s) from the interrupt (usually there will be some more
> completions waiting in the cq by the time the host start processing it).
> With irq-poll, we disable further interrupts and schedule soft-irq for
> processing, which if at all, improve the completions per interrupt
> utilization (because it takes slightly longer before processing the cq).
>
> Moreover, irq-poll is budgeting the completion queue processing which is
> important for a couple of reasons.
>
> 1. it prevents hard-irq context abuse like we do today. if other cpu
> cores are pounding with more submissions on the same queue, we might
> get into a hard-lockup (which I've seen happening).
>
> 2. irq-poll maintains fairness between devices by correctly budgeting
> the processing of different completions queues that share the same
> affinity. This can become crucial when working with multiple nvme
> devices, each has multiple io queues that share the same IRQ
> assignment.
>
> 3. It reduces (or at least should reduce) the overall number of
> interrupts in the system because we only enable interrupts again
> when the completion queue is completely processed.
>
> So overall, I think it's very useful for nvme and other modern HBAs,
> but unfortunately, other than solving (1), I wasn't able to see
> performance improvement but rather a slight regression, but I can't
> explain where its coming from...
Hello Sagi,
Thank you for the additional clarification. Although I am not sure whether
irq-poll is the ideal solution for the problems that has been described
above, I agree that it would help to discuss this topic further during
LSF/MM.
Bart.
_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
WARNING: multiple messages have this Message-ID (diff)
From: Bart.VanAssche@sandisk.com (Bart Van Assche)
Subject: [LSF/MM TOPIC][LSF/MM ATTEND] NAPI polling for block drivers
Date: Thu, 12 Jan 2017 19:13:17 +0000 [thread overview]
Message-ID: <1484248382.2720.9.camel@sandisk.com> (raw)
In-Reply-To: <ccb6cf4d-4810-47b2-015a-0202d784280a@grimberg.me>
On Thu, 2017-01-12@10:41 +0200, Sagi Grimberg wrote:
> First, when the nvme device fires an interrupt, the driver consumes
> the completion(s) from the interrupt (usually there will be some more
> completions waiting in the cq by the time the host start processing it).
> With irq-poll, we disable further interrupts and schedule soft-irq for
> processing, which if at all, improve the completions per interrupt
> utilization (because it takes slightly longer before processing the cq).
>
> Moreover, irq-poll is budgeting the completion queue processing which is
> important for a couple of reasons.
>
> 1. it prevents hard-irq context abuse like we do today. if other cpu
> cores are pounding with more submissions on the same queue, we might
> get into a hard-lockup (which I've seen happening).
>
> 2. irq-poll maintains fairness between devices by correctly budgeting
> the processing of different completions queues that share the same
> affinity. This can become crucial when working with multiple nvme
> devices, each has multiple io queues that share the same IRQ
> assignment.
>
> 3. It reduces (or at least should reduce) the overall number of
> interrupts in the system because we only enable interrupts again
> when the completion queue is completely processed.
>
> So overall, I think it's very useful for nvme and other modern HBAs,
> but unfortunately, other than solving (1), I wasn't able to see
> performance improvement but rather a slight regression, but I can't
> explain where its coming from...
Hello Sagi,
Thank you for the additional clarification. Although I am not sure whether
irq-poll is the ideal solution for the problems that has been described
above, I agree that it would help to discuss this topic further during
LSF/MM.
Bart.
WARNING: multiple messages have this Message-ID (diff)
From: Bart Van Assche <Bart.VanAssche@sandisk.com>
To: "jthumshirn@suse.de" <jthumshirn@suse.de>,
"lsf-pc@lists.linux-foundation.org"
<lsf-pc@lists.linux-foundation.org>,
"sagi@grimberg.me" <sagi@grimberg.me>
Cc: "Linux-scsi@vger.kernel.org" <Linux-scsi@vger.kernel.org>,
"hch@infradead.org" <hch@infradead.org>,
"keith.busch@intel.com" <keith.busch@intel.com>,
"linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>,
"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>
Subject: Re: [LSF/MM TOPIC][LSF/MM ATTEND] NAPI polling for block drivers
Date: Thu, 12 Jan 2017 19:13:17 +0000 [thread overview]
Message-ID: <1484248382.2720.9.camel@sandisk.com> (raw)
In-Reply-To: <ccb6cf4d-4810-47b2-015a-0202d784280a@grimberg.me>
On Thu, 2017-01-12 at 10:41 +0200, Sagi Grimberg wrote:
> First, when the nvme device fires an interrupt, the driver consumes
> the completion(s) from the interrupt (usually there will be some more
> completions waiting in the cq by the time the host start processing it).
> With irq-poll, we disable further interrupts and schedule soft-irq for
> processing, which if at all, improve the completions per interrupt
> utilization (because it takes slightly longer before processing the cq).
>
> Moreover, irq-poll is budgeting the completion queue processing which is
> important for a couple of reasons.
>
> 1. it prevents hard-irq context abuse like we do today. if other cpu
> cores are pounding with more submissions on the same queue, we might
> get into a hard-lockup (which I've seen happening).
>
> 2. irq-poll maintains fairness between devices by correctly budgeting
> the processing of different completions queues that share the same
> affinity. This can become crucial when working with multiple nvme
> devices, each has multiple io queues that share the same IRQ
> assignment.
>
> 3. It reduces (or at least should reduce) the overall number of
> interrupts in the system because we only enable interrupts again
> when the completion queue is completely processed.
>
> So overall, I think it's very useful for nvme and other modern HBAs,
> but unfortunately, other than solving (1), I wasn't able to see
> performance improvement but rather a slight regression, but I can't
> explain where its coming from...
Hello Sagi,
Thank you for the additional clarification. Although I am not sure whether
irq-poll is the ideal solution for the problems that has been described
above, I agree that it would help to discuss this topic further during
LSF/MM.
Bart.
next prev parent reply other threads:[~2017-01-12 19:13 UTC|newest]
Thread overview: 120+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-11 13:43 [LSF/MM TOPIC][LSF/MM ATTEND] NAPI polling for block drivers Johannes Thumshirn
2017-01-11 13:43 ` Johannes Thumshirn
2017-01-11 13:43 ` Johannes Thumshirn
2017-01-11 13:46 ` Hannes Reinecke
2017-01-11 13:46 ` Hannes Reinecke
2017-01-11 13:46 ` Hannes Reinecke
2017-01-11 15:07 ` Jens Axboe
2017-01-11 15:07 ` Jens Axboe
2017-01-11 15:13 ` Jens Axboe
2017-01-11 15:13 ` Jens Axboe
2017-01-12 8:23 ` Sagi Grimberg
2017-01-12 8:23 ` Sagi Grimberg
2017-01-12 10:02 ` Johannes Thumshirn
2017-01-12 10:02 ` Johannes Thumshirn
2017-01-12 10:02 ` Johannes Thumshirn
2017-01-12 11:44 ` Sagi Grimberg
2017-01-12 11:44 ` Sagi Grimberg
2017-01-12 12:53 ` Johannes Thumshirn
2017-01-12 12:53 ` Johannes Thumshirn
2017-01-12 12:53 ` Johannes Thumshirn
2017-01-12 14:41 ` [Lsf-pc] " Sagi Grimberg
2017-01-12 14:41 ` Sagi Grimberg
2017-01-12 18:59 ` Johannes Thumshirn
2017-01-12 18:59 ` Johannes Thumshirn
2017-01-12 18:59 ` Johannes Thumshirn
2017-01-17 15:38 ` Sagi Grimberg
2017-01-17 15:38 ` Sagi Grimberg
2017-01-17 15:45 ` Sagi Grimberg
2017-01-17 15:45 ` Sagi Grimberg
2017-01-20 12:22 ` Johannes Thumshirn
2017-01-20 12:22 ` Johannes Thumshirn
2017-01-20 12:22 ` Johannes Thumshirn
2017-01-17 16:15 ` Sagi Grimberg
2017-01-17 16:15 ` Sagi Grimberg
2017-01-17 16:27 ` Johannes Thumshirn
2017-01-17 16:27 ` Johannes Thumshirn
2017-01-17 16:27 ` Johannes Thumshirn
2017-01-17 16:38 ` Sagi Grimberg
2017-01-17 16:38 ` Sagi Grimberg
2017-01-18 13:51 ` Johannes Thumshirn
2017-01-18 13:51 ` Johannes Thumshirn
2017-01-18 13:51 ` Johannes Thumshirn
2017-01-18 14:27 ` Sagi Grimberg
2017-01-18 14:27 ` Sagi Grimberg
2017-01-18 14:36 ` Andrey Kuzmin
2017-01-18 14:36 ` Andrey Kuzmin
2017-01-18 14:40 ` Sagi Grimberg
2017-01-18 14:40 ` Sagi Grimberg
2017-01-18 15:35 ` Andrey Kuzmin
2017-01-18 15:35 ` Andrey Kuzmin
2017-01-18 14:58 ` Johannes Thumshirn
2017-01-18 14:58 ` Johannes Thumshirn
2017-01-18 14:58 ` Johannes Thumshirn
2017-01-18 15:14 ` Sagi Grimberg
2017-01-18 15:14 ` Sagi Grimberg
2017-01-18 15:16 ` Johannes Thumshirn
2017-01-18 15:16 ` Johannes Thumshirn
2017-01-18 15:16 ` Johannes Thumshirn
2017-01-18 15:39 ` Hannes Reinecke
2017-01-18 15:39 ` Hannes Reinecke
2017-01-18 15:39 ` Hannes Reinecke
2017-01-19 8:12 ` Sagi Grimberg
2017-01-19 8:12 ` Sagi Grimberg
2017-01-19 8:23 ` Sagi Grimberg
2017-01-19 8:23 ` Sagi Grimberg
2017-01-19 9:18 ` Johannes Thumshirn
2017-01-19 9:18 ` Johannes Thumshirn
2017-01-19 9:18 ` Johannes Thumshirn
2017-01-19 9:13 ` Johannes Thumshirn
2017-01-19 9:13 ` Johannes Thumshirn
2017-01-19 9:13 ` Johannes Thumshirn
2017-01-17 16:44 ` Andrey Kuzmin
2017-01-17 16:50 ` Sagi Grimberg
2017-01-17 16:50 ` Sagi Grimberg
2017-01-18 14:02 ` Hannes Reinecke
2017-01-18 14:02 ` Hannes Reinecke
2017-01-20 0:13 ` Jens Axboe
2017-01-20 0:13 ` Jens Axboe
2017-01-13 15:56 ` Johannes Thumshirn
2017-01-13 15:56 ` Johannes Thumshirn
2017-01-13 15:56 ` Johannes Thumshirn
2017-01-11 15:16 ` Hannes Reinecke
2017-01-11 15:16 ` Hannes Reinecke
2017-01-11 15:16 ` Hannes Reinecke
2017-01-12 4:36 ` Stephen Bates
2017-01-12 4:44 ` Jens Axboe
2017-01-12 4:44 ` Jens Axboe
2017-01-12 4:56 ` Stephen Bates
2017-01-12 4:56 ` Stephen Bates
2017-01-19 10:57 ` Ming Lei
2017-01-19 10:57 ` Ming Lei
2017-01-19 11:03 ` Hannes Reinecke
2017-01-19 11:03 ` Hannes Reinecke
2017-01-11 16:08 ` Bart Van Assche
2017-01-11 16:08 ` Bart Van Assche
2017-01-11 16:08 ` Bart Van Assche
2017-01-11 16:12 ` hch
2017-01-11 16:12 ` hch
2017-01-11 16:15 ` Jens Axboe
2017-01-11 16:15 ` Jens Axboe
2017-01-11 16:22 ` Hannes Reinecke
2017-01-11 16:22 ` Hannes Reinecke
2017-01-11 16:22 ` Hannes Reinecke
2017-01-11 16:26 ` Bart Van Assche
2017-01-11 16:26 ` Bart Van Assche
2017-01-11 16:26 ` Bart Van Assche
2017-01-11 16:45 ` Hannes Reinecke
2017-01-11 16:45 ` Hannes Reinecke
2017-01-11 16:45 ` Hannes Reinecke
2017-01-12 8:52 ` sagi grimberg
2017-01-12 8:52 ` sagi grimberg
2017-01-11 16:14 ` Johannes Thumshirn
2017-01-11 16:14 ` Johannes Thumshirn
2017-01-11 16:14 ` Johannes Thumshirn
2017-01-12 8:41 ` Sagi Grimberg
2017-01-12 8:41 ` Sagi Grimberg
2017-01-12 8:41 ` Sagi Grimberg
2017-01-12 19:13 ` Bart Van Assche [this message]
2017-01-12 19:13 ` Bart Van Assche
2017-01-12 19:13 ` Bart Van Assche
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=1484248382.2720.9.camel@sandisk.com \
--to=bart.vanassche@sandisk.com \
--cc=Linux-scsi@vger.kernel.org \
--cc=hch@infradead.org \
--cc=jthumshirn@suse.de \
--cc=keith.busch@intel.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=lsf-pc@lists.linux-foundation.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.