Messages in this thread | | | Date | Wed, 10 Mar 2010 01:50:37 +0100 | From | M vd S <> | Subject | Re: O_NONBLOCK is NOOP on block devices |
| |
> mmap(2) / madvise(2) / mincore(2) may be a way around things (although > non-atomic), but I haven't tested it yet. It might also solve the > problem that started this thread, at least for the reading part of it. > Writing a small read() like function that operates through mmap() > doesn't seem too complicated. As for writing, you could use msync() > with MS_ASYNC to initiate a write. I'm not sure how to find out if a > write has indeed taken place, but at least initiating a non-blocking > write is possible. munmap() might then still block. >
For the record I would like to share my very positive experience with the approach described. Thanks to 64 bit addressing you can mmap() an entire block device, and madvise() and mincore() work like you would expect them to. I haven't tried writing.
I also briefly tried aio_* and the libaio interface. The former is not really asynchronous - all requests are put in one separate thread where they will be executed in order, i.e. blocking, so you don't get any advantage from NCQ or data that was cached by the disk or the kernel. The latter apparently ends in an io_submit() which will block until all queued reads are finished, but I might have missed something there.
Imagine the orderly world in which O_NONBLOCK would make syscalls actually non-blocking...
Cheers, M.
| |