diff for duplicates of <1484150893.2619.1.camel@sandisk.com> diff --git a/a/1.txt b/N1/1.txt index e7900d2..7107178 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,23 +1,20 @@ -On Wed, 2017-01-11 at 14:43 +0100, Johannes Thumshirn wrote: +On Wed, 2017-01-11@14:43 +0100, Johannes Thumshirn wrote: > I'd like to attend LSF/MM and would like to discuss polling for block > drivers. ->=20 +> > 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. ->=20 -> On LSF/MM I'd like to whether it is desirable to have NAPI like polling i= -n +> +> 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. ->=20 -> [1] http://lists.infradead.org/pipermail/linux-nvme/2016-October/006975.h= -t +> +> [1] http://lists.infradead.org/pipermail/linux-nvme/2016-October/006975.ht > ml A typical Ethernet network adapter delays the generation of an interrupt -after it has received a packet. A typical block device or HBA does not dela= -y +after it has received a packet. A typical block device or HBA does not delay the generation of an interrupt that reports an I/O completion. I think that is why polling is more effective for network adapters than for block devices. I'm not sure whether it is possible to achieve benefits similar to @@ -32,4 +29,4 @@ An example of the interrupt coalescing parameters for a network adapter: rx-usecs: 3 tx-usecs: 0 -Bart.= +Bart. diff --git a/a/content_digest b/N1/content_digest index 2a66327..e06da6c 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -1,37 +1,26 @@ "ref\020170111134312.GH6286@linux-x5ow.site\0" - "From\0Bart Van Assche <Bart.VanAssche@sandisk.com>\0" - "Subject\0Re: [LSF/MM TOPIC][LSF/MM ATTEND] NAPI polling for block drivers\0" + "From\0Bart.VanAssche@sandisk.com (Bart Van Assche)\0" + "Subject\0[LSF/MM TOPIC][LSF/MM ATTEND] NAPI polling for block drivers\0" "Date\0Wed, 11 Jan 2017 16:08:31 +0000\0" - "To\0jthumshirn@suse.de <jthumshirn@suse.de>" - " lsf-pc@lists.linux-foundation.org <lsf-pc@lists.linux-foundation.org>\0" - "Cc\0Linux-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> - " sagi@grimberg.me <sagi@grimberg.me>\0" "\00:1\0" "b\0" - "On Wed, 2017-01-11 at 14:43 +0100, Johannes Thumshirn wrote:\n" + "On Wed, 2017-01-11@14:43 +0100, Johannes Thumshirn wrote:\n" "> I'd like to attend LSF/MM and would like to discuss polling for block\n" "> drivers.\n" - ">=20\n" + "> \n" "> Currently there is blk-iopoll but it is neither as widely used as NAPI in\n" "> the networking field and accoring to Sagi's findings in [1] performance\n" "> with polling is not on par with IRQ usage.\n" - ">=20\n" - "> On LSF/MM I'd like to whether it is desirable to have NAPI like polling i=\n" - "n\n" + "> \n" + "> On LSF/MM I'd like to whether it is desirable to have NAPI like polling in\n" "> more block drivers and how to overcome the currently seen performance\n" "> issues.\n" - ">=20\n" - "> [1] http://lists.infradead.org/pipermail/linux-nvme/2016-October/006975.h=\n" - "t\n" + "> \n" + "> [1] http://lists.infradead.org/pipermail/linux-nvme/2016-October/006975.ht\n" "> ml\n" "\n" "A typical Ethernet network adapter delays the generation of an interrupt\n" - "after it has received a packet. A typical block device or HBA does not dela=\n" - "y\n" + "after it has received a packet. A typical block device or HBA does not delay\n" "the generation of an interrupt that reports an I/O completion. I think that\n" "is why polling is more effective for network adapters than for block\n" "devices. I'm not sure whether it is possible to achieve benefits similar to\n" @@ -46,6 +35,6 @@ "rx-usecs: 3\n" "tx-usecs: 0\n" "\n" - Bart.= + Bart. -abf77a8c2be6b97ed5ea5d45a59b65fe4970c8763f1c29dbc170c63103866429 +d0df0e024069f3b8b19a76aa4b204954428dede721e3f51ce80bc28363cae20c
diff --git a/a/1.txt b/N2/1.txt index e7900d2..203419a 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -1,23 +1,20 @@ On Wed, 2017-01-11 at 14:43 +0100, Johannes Thumshirn wrote: > I'd like to attend LSF/MM and would like to discuss polling for block > drivers. ->=20 +> > 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. ->=20 -> On LSF/MM I'd like to whether it is desirable to have NAPI like polling i= -n +> +> 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. ->=20 -> [1] http://lists.infradead.org/pipermail/linux-nvme/2016-October/006975.h= -t +> +> [1] http://lists.infradead.org/pipermail/linux-nvme/2016-October/006975.ht > ml A typical Ethernet network adapter delays the generation of an interrupt -after it has received a packet. A typical block device or HBA does not dela= -y +after it has received a packet. A typical block device or HBA does not delay the generation of an interrupt that reports an I/O completion. I think that is why polling is more effective for network adapters than for block devices. I'm not sure whether it is possible to achieve benefits similar to @@ -32,4 +29,4 @@ An example of the interrupt coalescing parameters for a network adapter: rx-usecs: 3 tx-usecs: 0 -Bart.= +Bart. diff --git a/a/content_digest b/N2/content_digest index 2a66327..2459730 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -15,23 +15,20 @@ "On Wed, 2017-01-11 at 14:43 +0100, Johannes Thumshirn wrote:\n" "> I'd like to attend LSF/MM and would like to discuss polling for block\n" "> drivers.\n" - ">=20\n" + "> \n" "> Currently there is blk-iopoll but it is neither as widely used as NAPI in\n" "> the networking field and accoring to Sagi's findings in [1] performance\n" "> with polling is not on par with IRQ usage.\n" - ">=20\n" - "> On LSF/MM I'd like to whether it is desirable to have NAPI like polling i=\n" - "n\n" + "> \n" + "> On LSF/MM I'd like to whether it is desirable to have NAPI like polling in\n" "> more block drivers and how to overcome the currently seen performance\n" "> issues.\n" - ">=20\n" - "> [1] http://lists.infradead.org/pipermail/linux-nvme/2016-October/006975.h=\n" - "t\n" + "> \n" + "> [1] http://lists.infradead.org/pipermail/linux-nvme/2016-October/006975.ht\n" "> ml\n" "\n" "A typical Ethernet network adapter delays the generation of an interrupt\n" - "after it has received a packet. A typical block device or HBA does not dela=\n" - "y\n" + "after it has received a packet. A typical block device or HBA does not delay\n" "the generation of an interrupt that reports an I/O completion. I think that\n" "is why polling is more effective for network adapters than for block\n" "devices. I'm not sure whether it is possible to achieve benefits similar to\n" @@ -46,6 +43,6 @@ "rx-usecs: 3\n" "tx-usecs: 0\n" "\n" - Bart.= + Bart. -abf77a8c2be6b97ed5ea5d45a59b65fe4970c8763f1c29dbc170c63103866429 +744200ffd2dbcdae04e4b7e0b2a4d57374bee0bdb60e4757fadb36bfb80fb320
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.