Messages in this thread | | | From | Jeff Moyer <> | Date | Mon, 18 Oct 2004 12:51:28 -0400 | Subject | Re: [patch rfc] towards supporting O_NONBLOCK on regular files |
| |
==> Regarding Re: [patch rfc] towards supporting O_NONBLOCK on regular files; Alexandre Oliva <aoliva@redhat.com> adds:
aoliva> On Oct 17, 2004, Ingo Molnar <mingo@redhat.com> wrote: >> I.e. the readahead-kicking is necessary after all, because squid >> apparently assumes that re-trying a read will eventually succeed.
aoliva> I'm not sure it assumes that. It definitely expects read to aoliva> succeed if poll says there is data available from the file, though, aoliva> and having poll return that there is data, and then having read aoliva> fail because there isn't anything there, so that you go back to aoliva> poll, is a recipe for wasting CPU. I do think read should kick in aoliva> readahead, yes, but so should poll, if the process says it wants to aoliva> read from the file, and poll should not return (or not say data is aoliva> available) unless an immediate, atomic call to read would actually aoliva> return some data. Of course, if the data happens to be elicited aoliva> from memory between the poll and read calls, it's legitimate for aoliva> read to fail with -EAGAIN, but this shouldn't happen very often.
Select, pselect, and poll will always return data ready on a regular file. As such, I would argue that squid's behaviour is broken. Additionally, I don't think it's a good idea to modify any polling mechanism to kick off I/O, if simply because I'm not sure how much data to request!
Since it wasn't supported before, I see no need to extend select/poll to change behaviour for regular files. After all, the POSIX spec explicitly says that select and friends will always return data ready for regular files. To make O_NONBLOCK on regular files a workable implementation, Uli suggestsed extending epoll. I will look into this.
I am in favor of kicking off I/O for reads that would block.
-Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |