From: Jens Axboe <axboe@kernel.dk>
To: Stephen Bates <sbates@raithlin.com>
Cc: Johannes Thumshirn <jthumshirn@suse.de>,
"lsf-pc@lists.linux-foundation.org"
<lsf-pc@lists.linux-foundation.org>,
Christoph Hellwig <hch@infradead.org>,
Sagi Grimberg <sagi@grimberg.me>,
linux-scsi@vger.kernel.org, linux-nvme@lists.infradead.org,
linux-block@vger.kernel.org, Keith Busch <keith.busch@intel.com>
Subject: Re: [LSF/MM TOPIC][LSF/MM ATTEND] NAPI polling for block drivers
Date: Wed, 11 Jan 2017 21:44:05 -0700 [thread overview]
Message-ID: <43b42605-0c97-ca33-2e39-5ec58b441bcc@kernel.dk> (raw)
In-Reply-To: <43b3038b57ed5c00a73ebc5457d048d5.squirrel@webmail.raithlin.com>
On 01/11/2017 09:36 PM, Stephen Bates wrote:
>>>
>>> I'd like to attend LSF/MM and would like to discuss polling for block
>>> drivers.
>>>
>>> Currently there is blk-iopoll but it is neither as widely used as NAPI
>>> in the networking field and accoring to Sagi's findings in [1]
>>> performance with polling is not on par with IRQ usage.
>>>
>>> On LSF/MM I'd like to whether it is desirable to have NAPI like polling
>>> in more block drivers and how to overcome the currently seen performance
>>> issues.
>>
>> It would be an interesting topic to discuss, as it is a shame that
>> blk-iopoll isn't used more widely.
>>
>> --
>> Jens Axboe
>>
>
> I'd also be interested in this topic. Given that iopoll only really makes
> sense for low-latency, low queue depth environments (i.e. down below
> 10-20us) I'd like to discuss which drivers we think will need/want to be
> upgraded (aside from NVMe ;-)).
>
> I'd also be interested in discussing how best to enable and disable
> polling. In the past some of us have pushed for a "big hammer" to turn
> polling on for a given device or HW queue [1]. I'd like to discuss this
> again as well as looking at other methods above and beyond the preadv2
> system call and the HIPRI flag.
This is a separate topic. The initial proposal is for polling for
interrupt mitigation, you are talking about polling in the context of
polling for completion of an IO.
We can definitely talk about this form of polling as well, but it should
be a separate topic and probably proposed independently.
--
Jens Axboe
next prev parent reply other threads:[~2017-01-12 4:44 UTC|newest]
Thread overview: 49+ 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:46 ` Hannes Reinecke
2017-01-11 15:07 ` Jens Axboe
2017-01-11 15:13 ` Jens Axboe
2017-01-12 8:23 ` Sagi Grimberg
2017-01-12 10:02 ` Johannes Thumshirn
2017-01-12 11:44 ` Sagi Grimberg
2017-01-12 12:53 ` Johannes Thumshirn
2017-01-12 14:41 ` [Lsf-pc] " Sagi Grimberg
2017-01-12 18:59 ` Johannes Thumshirn
2017-01-17 15:38 ` Sagi Grimberg
2017-01-17 15:45 ` Sagi Grimberg
2017-01-20 12:22 ` Johannes Thumshirn
2017-01-17 16:15 ` Sagi Grimberg
2017-01-17 16:27 ` Johannes Thumshirn
2017-01-17 16:38 ` Sagi Grimberg
2017-01-18 13:51 ` Johannes Thumshirn
2017-01-18 14:27 ` Sagi Grimberg
2017-01-18 14:36 ` Andrey Kuzmin
2017-01-18 14:40 ` Sagi Grimberg
2017-01-18 15:35 ` Andrey Kuzmin
2017-01-18 14:58 ` Johannes Thumshirn
2017-01-18 15:14 ` Sagi Grimberg
2017-01-18 15:16 ` Johannes Thumshirn
2017-01-18 15:39 ` Hannes Reinecke
2017-01-19 8:12 ` Sagi Grimberg
2017-01-19 8:23 ` Sagi Grimberg
2017-01-19 9:18 ` Johannes Thumshirn
2017-01-19 9:13 ` Johannes Thumshirn
[not found] ` <CANvN+emx1-F3iAY45t1_MQRcijw7sf1jPvjwv0uh8A3GzzQwMg@mail.gmail.com>
2017-01-17 16:50 ` Sagi Grimberg
2017-01-18 14:02 ` Hannes Reinecke
2017-01-20 0:13 ` Jens Axboe
2017-01-13 15:56 ` Johannes Thumshirn
2017-01-11 15:16 ` Hannes Reinecke
2017-01-12 4:36 ` Stephen Bates
2017-01-12 4:44 ` Jens Axboe [this message]
2017-01-12 4:56 ` Stephen Bates
2017-01-19 10:57 ` Ming Lei
2017-01-19 11:03 ` Hannes Reinecke
2017-01-11 16:08 ` Bart Van Assche
2017-01-11 16:12 ` hch
2017-01-11 16:15 ` Jens Axboe
2017-01-11 16:22 ` Hannes Reinecke
2017-01-11 16:26 ` Bart Van Assche
2017-01-11 16:45 ` Hannes Reinecke
2017-01-12 8:52 ` sagi grimberg
2017-01-11 16:14 ` Johannes Thumshirn
2017-01-12 8:41 ` Sagi Grimberg
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=43b42605-0c97-ca33-2e39-5ec58b441bcc@kernel.dk \
--to=axboe@kernel.dk \
--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=linux-scsi@vger.kernel.org \
--cc=lsf-pc@lists.linux-foundation.org \
--cc=sagi@grimberg.me \
--cc=sbates@raithlin.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox