Re: [PATCHSET v3] block: IO polling improvements

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 11/16/2016 10:31 AM, Stephen Bates wrote:
On Fri, November 11, 2016 11:11 pm, Jens Axboe wrote:
Respun on top of for-4.10/block, dropping patches that have been
merged. This patchset adds Christoph's simplified sync O_DIRECT bdev access
mode, and implements a more efficient IO polling on top of it. For more
details, see the v2 posting here:

http://www.mail-archive.com/linux-block@xxxxxxxxxxxxxxx/msg02079.html


Changes since v2:


- Adapt to blk stat changes
- Make it explicit that only blk-mq supports polling
- Fix a bug in the hrtimer code, switching to absolute mode if we
have to loop around (thanks Omar).


Hi Jens

I applied this series cleanly on top of 2868f13c303e147 in your
for-4.10/block branch. I tested using a simple fio wrapper script [1] on a
low-latency NVMe SSD [2]. Here are some results:

io_poll  io_poll_delay  threads  latency  CPU/threads

0        N/A            1        17.0     47%
1        -1             1        13.8     100%
1        0              1        14.6     73%
1        10             1        17.0     56%

0        N/A            8        18.7     47%
1        -1             8        14.4     100%
1        0              8        15.7     73%
1        10             8        19.0     56%

The io_poll_delay option 0 is definitely a nice compromise between no
polling and 100% polling. The result for io_poll_delay=10us is interesting
as it implies there might be some mismatch between that value and the
completion time. However I think that is something we can improve on over
time and I don't see it as a reason to not get this series upstream.

For the series:

Tested-By: Stephen Bates <sbates@xxxxxxxxxxxx>
Reviewed-By: Stephen Bates <sbates@xxxxxxxxxxxx>

Thanks for testing, Stephen, I'll add your tested/reviewed-by tags. As
to the specific setting of the time, it might just be that it's a poor
choice of value. We'll need some time to setup the delay, and if we end
up being late, then we'll make things worse. But I agree, we can look
into that going forward. I've got some more ideas on how to improve the
timing in general, so we can both get closer to -1 and get better
efficiency as well.

--
Jens Axboe

--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux