From mboxrd@z Thu Jan 1 00:00:00 1970 From: jthumshirn@suse.de (Johannes Thumshirn) Date: Thu, 12 Jan 2017 19:59:34 +0100 Subject: [Lsf-pc] [LSF/MM TOPIC][LSF/MM ATTEND] NAPI polling for block drivers In-Reply-To: <91262998-8dd7-107a-06e7-6f333df59a91@grimberg.me> References: <20170111134312.GH6286@linux-x5ow.site> <8b47ca34-d2ff-26dc-721e-2cb1e18f1efc@grimberg.me> <20170112100251.GB3598@linux-x5ow.site> <879a91ba-eff7-682d-12a9-5d83f26e7e09@grimberg.me> <20170112125338.GH3598@linux-x5ow.site> <91262998-8dd7-107a-06e7-6f333df59a91@grimberg.me> Message-ID: <20170112185933.GA3554@linux-x5ow.site> On Thu, Jan 12, 2017@04:41:00PM +0200, Sagi Grimberg wrote: > > >>**Note: when I ran multiple threads on more cpus the performance > >>degradation phenomenon disappeared, but I tested on a VM with > >>qemu emulation backed by null_blk so I figured I had some other > >>bottleneck somewhere (that's why I asked for some more testing). > > > >That could be because of the vmexits as every MMIO access in the guest > >triggers a vmexit and if you poll with a low budget you do more MMIOs hence > >you have more vmexits. > > > >Did you do testing only in qemu or with real H/W as well? > > I tried once. IIRC, I saw the same phenomenons... JFTR I tried my AHCI irq_poll patch on the Qemu emulation and the read throughput dropped from ~1GB/s to ~350MB/s. But this can be related to Qemu's I/O wiredness as well I think. I'll try on real hardware tomorrow. -- Johannes Thumshirn Storage jthumshirn at suse.de +49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 N?rnberg GF: Felix Imend?rffer, Jane Smithard, Graham Norton HRB 21284 (AG N?rnberg) Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850