Re: [LSF/MM TOPIC][LSF/MM ATTEND] NAPI polling for block drivers
On Wed, Jan 18, 2017 at 5:40 PM, Sagi Grimberg wrote: > >> Your report provided this stats with one-completion dominance for the >> single-threaded case. Does it also hold if you run multiple fio >> threads per core? > > > It's useless to run more threads on that core, it's already fully > utilized. That single threads is already posting a fair amount of > submissions, so I don't see how adding more fio jobs can help in any > way. With a single thread, your completion processing/submission is completely serialized. From my experience, it takes fio couple of microsec to process completion and submit next request, and that' (much) larger than your interrupt processing time. Regards, Andrey -- To unsubscribe from this list: send the line "unsubscribe linux-block" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [LSF/MM TOPIC][LSF/MM ATTEND] NAPI polling for block drivers
On Wed, Jan 18, 2017 at 5:27 PM, Sagi Grimberg wrote: > >> So what you say is you saw a consomed == 1 [1] most of the time? >> >> [1] from >> http://git.infradead.org/nvme.git/commitdiff/eed5a9d925c59e43980047059fde29e3aa0b7836 > > > Exactly. By processing 1 completion per interrupt it makes perfect sense > why this performs poorly, it's not worth paying the soft-irq schedule > for only a single completion. Your report provided this stats with one-completion dominance for the single-threaded case. Does it also hold if you run multiple fio threads per core? Regards, Andrey > > What I'm curious is how consistent is this with different devices (wish > I had some...) > > > ___ > Linux-nvme mailing list > linux-n...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-nvme -- To unsubscribe from this list: send the line "unsubscribe linux-block" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
