# Re: selective block polling and preadv2/pwritev2 revisited V2 - List: linux-api - 3 messages, 3 authors - Page: https://ratatoskr.run/linux-api/2016/02/104287/t ## Re: selective block polling and preadv2/pwritev2 revisited V2 - From: Jeff Moyer \ - Date: 2016-02-26 21:18:57 - Message: https://ratatoskr.run/linux-api/2016/02/104287.md ```text Christoph Hellwig [ref] writes: > This series allows to selectively enable/disable polling for completions > in the block layer on a per-I/O basis. For this it resurrects the > preadv2/pwritev2 syscalls that Milosz prepared a while ago (and which > are much simpler now due to VFS changes that happened in the meantime). > That approach also had a man page update prepared, which I will resubmit > with the current flags once this series makes it in. It would be helpful for reviewers if you submitted the man page at the same time, in my opinion. Do you have any plans on adding polling support to the buffered path? > Polling for block I/O is important to reduce the latency on flash and > post-flash storage technologies. On the fastest NVMe controller I have > access to it almost halves latencies from over 7 microseconds to about 4 > microseonds. But it only is usesful if we actually care for the latency > of this particular I/O, and generally is a waste if enabled for all I/O > to a given device. This series uses the per-I/O flags in preadv2/pwritev2 > to control this behavior. The alternative would be a new O_* flag set > at open time or using fcntl, but this is still to corse-grained for some > applications and we're starting to run out out of open flags. I agree that a per-I/O mechanism is better suited to this application. > Note that there are plenty of other use cases for preadv2/pwritev2 as well, > but I'd like to concentrate on this one for now. Example are: non-blocking > reads (the original purpose), per-I/O O_SYNC, user space support for T10 > DIF/DIX applications tags and probably some more. And my favorite, RWF_ATOMIC. :) I agree, it's time we got this interface in. See responses to individual patches for my review. Cheers, Jeff ``` ## Re: selective block polling and preadv2/pwritev2 revisited V2 - From: Christoph Hellwig \ - Date: 2016-02-27 08:57:47 - Message: https://ratatoskr.run/linux-api/2016/02/104286.md ```text On Fri, Feb 26, 2016 at 04:18:55PM -0500, Jeff Moyer wrote: > Christoph Hellwig [ref] writes: > > > This series allows to selectively enable/disable polling for completions > > in the block layer on a per-I/O basis. For this it resurrects the > > preadv2/pwritev2 syscalls that Milosz prepared a while ago (and which > > are much simpler now due to VFS changes that happened in the meantime). > > That approach also had a man page update prepared, which I will resubmit > > with the current flags once this series makes it in. > > It would be helpful for reviewers if you submitted the man page at the > same time, in my opinion. Ok. > Do you have any plans on adding polling support to the buffered path? How would that even make sense? ``` ## Re: selective block polling and preadv2/pwritev2 revisited V2 - From: Damien Le Moal \ - Date: 2016-02-29 01:41:00 - Message: https://ratatoskr.run/linux-api/2016/02/104285.md ```text >On Fri, Feb 26, 2016 at 04:18:55PM -0500, Jeff Moyer wrote: >> Christoph Hellwig [ref] writes: >> >> > This series allows to selectively enable/disable polling for completions >> > in the block layer on a per-I/O basis. For this it resurrects the >> > preadv2/pwritev2 syscalls that Milosz prepared a while ago (and which >> > are much simpler now due to VFS changes that happened in the meantime). >> > That approach also had a man page update prepared, which I will resubmit >> > with the current flags once this series makes it in. >> >> It would be helpful for reviewers if you submitted the man page at the >> same time, in my opinion. > >Ok. > >> Do you have any plans on adding polling support to the buffered path? > >How would that even make sense? Christoph, On a page cache miss, poll for the BIO serving the page read instead of waiting for the page lock to be released (from device IRQ handler) ? As long as the application is lucky to get a fast page allocation, similar performance improvements as direct I/Os should be observed, shouldn't it ? Benefit may be restricted to very random accesses. For reasonably sequential accesses, read-ahead would cover, and obviously, no polling there. So may be polling could be enabled only if read-ahead is disabled. Interestingly, if the device+bus is really really fast, that could result in minimal performance difference between a page cache hit and a miss... Best. > ------------------------ Damien Le Moal, Ph.D. Sr. Manager, System Software Group, HGST Research, HGST, a Western Digital company Damien.LeMoal@hgst.com (+81) 0466-98-3593 (ext. 513593) 1 kirihara-cho, Fujisawa, Kanagawa, 252-0888 Japan www.hgst.com Western Digital Corporation (and its subsidiaries) E-mail Confidentiality Notice & Disclaimer: This e-mail and any files transmitted with it may contain confidential or legally privileged information of WDC and/or its affiliates, and are intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited. If you have received this e-mail in error, please notify the sender immediately and delete the e-mail in its entirety from your system. ```