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

  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.