lkml.org 
[lkml]   [2010]   [Mar]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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.



\
 
 \ /
  Last update: 2010-03-10 01:53    [W:0.048 / U:0.384 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site