From: Jeff Moyer <jmoyer@redhat.com>
To: "Stephen C. Tweedie" <sct@redhat.com>,
Marcelo Tosatti <marcelo.tosatti@cyclades.com>,
linux-kernel <linux-kernel@vger.kernel.org>,
Ingo Molnar <mingo@redhat.com>,
akpm@osdl.org
Subject: Re: [patch rfc] towards supporting O_NONBLOCK on regular files
Date: Fri, 15 Oct 2004 11:44:57 -0400 [thread overview]
Message-ID: <16751.61561.156429.120130@segfault.boston.redhat.com> (raw)
In-Reply-To: <16749.15133.627859.786023@segfault.boston.redhat.com>
[-- Attachment #1: message body text --]
[-- Type: text/plain, Size: 1758 bytes --]
==> Regarding Re: [patch rfc] towards supporting O_NONBLOCK on regular files; Jeff Moyer <jmoyer@redhat.com> adds:
==> Regarding Re: [patch rfc] towards supporting O_NONBLOCK on regular files; "Stephen C. Tweedie" <sct@redhat.com> adds:
sct> Hi, On Mon, 2004-10-11 at 19:58, Jeff Moyer wrote:
sct> I think it's worth getting this right in the long term, though.
sct> Getting readahead of indirect blocks right has other benefits too ---
sct> eg. we may be able to fix the situation where we end up trying to read
sct> indirect blocks before we've even submitted the IO for the previous
sct> data blocks, breaking the IO pipeline ordering.
>>> So for the short term, are you an advocate of the patch posted?
sct> In the short term, can't we just disable readahead for O_NONBLOCK?
sct> That has true non-blocking semantics --- if the data is already
sct> available we return it, but if not, it's up to somebody else to
sct> retrieve it.
sct> That's exactly what you want if you're genuinely trying to avoid
sct> blocking at all costs on a really hot event loop, and the semantics
sct> seem to make sense to me. It's not that different from the networking
sct> case where no amount of read() on a non-blocking fd will get you more
sct> data unless there's another process somewhere filling the stream.
jmoyer> Yes, that sounds like a fine idea. Here is a patch which does
jmoyer> this. Andrew, I know you only want bug fixes, but I'd like to get
jmoyer> this into your queue for post 2.6.9, if possible.
I got the partial read case wrong in the last patch. In fact, it looks
like this code path would perform infinite retries before. This should
address that by returning upon the first partial read. Attached is a new
version of the patch.
-Jeff
[-- Attachment #2: linux-2.6.9-o_nonblock-2.patch --]
[-- Type: text/plain, Size: 1452 bytes --]
--- linux-2.6.9-rc4-mm1/mm/filemap.c.orig 2004-10-15 10:33:24.986209880 -0400
+++ linux-2.6.9-rc4-mm1/mm/filemap.c 2004-10-15 11:38:50.869384920 -0400
@@ -692,7 +692,7 @@ void do_generic_mapping_read(struct addr
unsigned long index, end_index, offset;
loff_t isize;
struct page *cached_page;
- int error;
+ int error, nonblock = filp->f_flags & O_NONBLOCK;
struct file_ra_state ra = *_ra;
cached_page = NULL;
@@ -721,16 +721,27 @@ void do_generic_mapping_read(struct addr
nr = nr - offset;
cond_resched();
- page_cache_readahead(mapping, &ra, filp, index);
+ if (!nonblock)
+ page_cache_readahead(mapping, &ra, filp, index);
find_page:
page = find_get_page(mapping, index);
if (unlikely(page == NULL)) {
+ if (nonblock) {
+ desc->error = -EWOULDBLOCK;
+ break;
+ }
handle_ra_miss(mapping, &ra, index);
goto no_cached_page;
}
- if (!PageUptodate(page))
+ if (!PageUptodate(page)) {
+ if (nonblock) {
+ page_cache_release(page);
+ desc->error = -EWOULDBLOCK;
+ break;
+ }
goto page_not_up_to_date;
+ }
page_ok:
/* If users can be writing to this page using arbitrary
@@ -976,10 +987,10 @@ __generic_file_aio_read(struct kiocb *io
desc.error = 0;
do_generic_file_read(filp,ppos,&desc,file_read_actor);
retval += desc.written;
- if (!retval) {
+ if (!retval)
retval = desc.error;
+ if (desc.written != iov[seg].iov_len)
break;
- }
}
}
out:
next prev parent reply other threads:[~2004-10-15 15:47 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-01 20:57 Jeff Moyer
2004-10-03 19:48 ` Pavel Machek
2004-10-13 14:28 ` Jeff Moyer
2004-10-14 17:39 ` Pavel Machek
2004-10-05 11:27 ` Marcelo Tosatti
2004-10-06 13:13 ` Jeff Moyer
2004-10-06 12:01 ` Marcelo Tosatti
2004-10-07 3:31 ` Stephen C. Tweedie
2004-10-07 10:12 ` Marcelo Tosatti
2004-10-07 12:30 ` Arjan van de Ven
2004-10-11 18:32 ` Stephen C. Tweedie
2004-10-11 18:58 ` Jeff Moyer
2004-10-11 21:49 ` Stephen C. Tweedie
2004-10-13 14:26 ` Jeff Moyer
2004-10-15 15:44 ` Jeff Moyer [this message]
2004-10-15 16:19 ` Stephen C. Tweedie
2004-10-17 7:59 ` Alexandre Oliva
2004-10-17 11:20 ` Ingo Molnar
2004-10-17 19:38 ` Alexandre Oliva
2004-10-18 16:51 ` Jeff Moyer
2004-10-19 6:04 ` Alexandre Oliva
2004-10-21 20:14 ` James Antill
2004-10-05 15:35 ` Rik van Riel
2004-10-05 13:07 Dan Kegel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=16751.61561.156429.120130@segfault.boston.redhat.com \
--to=jmoyer@redhat.com \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marcelo.tosatti@cyclades.com \
--cc=mingo@redhat.com \
--cc=sct@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome