From: Jeff Moyer <jmoyer@redhat.com>
To: "Stephen C. Tweedie" <sct@redhat.com>
Cc: Marcelo Tosatti <marcelo.tosatti@cyclades.com>,
linux-kernel <linux-kernel@vger.kernel.org>,
Ingo Molnar <mingo@redhat.com>
Subject: Re: [patch rfc] towards supporting O_NONBLOCK on regular files
Date: Mon, 11 Oct 2004 14:58:59 -0400 [thread overview]
Message-ID: <16746.55283.192591.718383@segfault.boston.redhat.com> (raw)
In-Reply-To: <1097519553.2128.115.camel@sisko.scot.redhat.com>
==> Regarding Re: [patch rfc] towards supporting O_NONBLOCK on regular files; "Stephen C. Tweedie" <sct@redhat.com> adds:
sct> Hi, On Thu, 2004-10-07 at 11:12, Marcelo Tosatti wrote:
>> Oh yes, theres also the indirect blocks which we might need to read from
>> disk.
sct> Right.
>> Now the question is, how strict should the O_NONBLOCK implementation be
>> in reference to "not blocking" ?
sct> Well, I suspect that depends on the application. But if you've got an
sct> app that really wants to make sure its hot path is as fast as possible
sct> (eg. a high-throughput server multiplexing disk IO and networking
sct> through a single event loop), then ideally the app would want to punt
sct> any blocking disk IO to another thread.
sct> So it's a matter of significant extra programing for a small extra
sct> reduction in app blocking potential.
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?
-Jeff
next prev parent reply other threads:[~2004-10-11 19:00 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 [this message]
2004-10-11 21:49 ` Stephen C. Tweedie
2004-10-13 14:26 ` Jeff Moyer
2004-10-15 15:44 ` Jeff Moyer
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=16746.55283.192591.718383@segfault.boston.redhat.com \
--to=jmoyer@redhat.com \
--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
all inboxes | Powered by JetHome®