Messages in this thread | | | Subject | Re: [PATCH 1/9] move blk_iopoll to limit and make it generally available | From | Sagi Grimberg <> | Date | Sun, 15 Nov 2015 15:16:46 +0200 |
| |
On 15/11/2015 11:04, Or Gerlitz wrote: > On Sun, Nov 15, 2015 at 10:48 AM, Sagi Grimberg > <sagig@dev.mellanox.co.il> wrote: >> Or is correct, >> >> I have attempted to convert iser to use blk_iopoll in the past, however >> I've seen inconsistent performance and latency skews (comparing to >> tasklets iser is using today). This was manifested in IOPs test cases >> where I ran multiple threads with higher queue-depth and not in >> sanitized pure latency (QD=1) test cases. Unfortunately I didn't have >> the time to pick it up since. >> >> I do have every intention of testing it again with this. If it still >> exist we will need to find the root-cause of it before converting >> drivers to use it. > > Good, this way (inconsistent performance and latency skews) or another > (all shines up) -- please > let us know your findings, best through commenting within V > 0 the > cover letter posts of this series >
Hi Or & Co,
I ran some tests on the iser code with this patchset applied. I can confirm that I did not see any performance degradations. summary (on my test servers): 1 LUN: ~530K (IOPs) 2 LUNs: ~1080K (IOPs) 4 LUNs: ~1350K (IOPs) 8 LUNs: ~1930K (IOPs) 16 LUns: ~2250K (IOPs)
These results are true both for tasklet and iopoll.
So, I don't have anything smart to say here, the IO stack (block, scsi) has gone through major changes since the last time I looked into this, so it'll be pretty hard to figure out what was the root cause back then...
Sagi.
| |