Prev: sch_gpio: fix compilation warning "ignoring return value of gpiochip_remove"
Next: [PATCH] timbgpio: Fix build.
From: Jeff Moyer on 5 Mar 2010 11:10
M vd S <mvds.00(a)gmail.com> writes:

>> > > If O_NONBLOCK is meaningful whatsoever (see man page docs for
>> > > semantics) against block devices, one would expect a nonblocking io
>> >
>> > It isn't...
>>
>> Thanks for the reply. It's good to get confirmation that I am not all
>> alone in an alternate non blocking universe. The linux man pages
>> actually had me convinced O_NONBLOCK would actually keep a process
>> from blocking on device io :-)
>>
>
> You're even less alone, I'm running into the same issue just now. But
> I think I've found a way around it, see below.

I guess I should note that I've suggested nonblocking I/O for files
before:

http://linux.derkeiler.com/Mailing-Lists/Kernel/2004-10/0290.html

I'll also note that enabling such a patch broke apps that accessed cd
burners, for example, since O_NONBLOCK had some preexisting semantics
there that I fail to recall.

Cheers,
Jeff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Mike Hayward on 5 Mar 2010 15:00
Hi Jeff,

> I guess I should note that I've suggested nonblocking I/O for files
> before:
>
> http://linux.derkeiler.com/Mailing-Lists/Kernel/2004-10/0290.html
>
> I'll also note that enabling such a patch broke apps that accessed cd
> burners, for example, since O_NONBLOCK had some preexisting semantics
> there that I fail to recall.

Sounds like nonblocking read/write calls are strongly tied to threads
instead of state related to a file descriptor. I haven't poked around
in there, but perhaps the current linux io architecture is just too
set in stone to design an efficient non blocking mechanism. It would
be a shame not to fix it simply because some broken apps depend upon
blocking behavior when they have been explicitly specifying O_NONBLOCK
via open or fcntl.

At least for now we can describe it's actual behavior in the man
pages; I will be submitting a man page patch for consideration later
today.

- Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: M vd S on 9 Mar 2010 20:00

> 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.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Jeff Moyer on 10 Mar 2010 08:30
M vd S <mvds.00(a)gmail.com> writes:
> 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.

What you missed is that the native aio system calls require O_DIRECT.

Cheers,
Jeff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: M vd S on 10 Mar 2010 12:20
On 3/10/10 2:21 PM, Jeff Moyer wrote:
> M vd S <mvds.00(a)gmail.com> writes:
>
>> 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.
>>
>
> What you missed is that the native aio system calls require O_DIRECT.
>

Thanks, that made it work. It seems without O_DIRECT it's just like
aio_* but without the separate thread. But I now get the "benefits" of
O_DIRECT for free...

Cheers,
M.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: sch_gpio: fix compilation warning "ignoring return value of gpiochip_remove"
Next: [PATCH] timbgpio: Fix build.