9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: sqweek <sqweek@gmail.com>
To: "erik quanstrom" <quanstro@quanstro.net>
Cc: 9fans@9fans.net
Subject: Re: [9fans] 9p over high-latency
Date: Thu, 18 Sep 2008 21:34:43 +0800	[thread overview]
Message-ID: <140e7ec30809180634p393897b2r2bb7eed6cc8060ee@mail.gmail.com> (raw)
In-Reply-To: <0a44b94d5b9fa0b13dc1d9ae11472e5e@quanstro.net>

On Thu, Sep 18, 2008 at 7:51 PM, erik quanstrom <quanstro@quanstro.net> wrote:
>>  Hm, but what's the alternative here? Readahead seems somewhat
>> attractive, if difficult (I worry about blocking reads and timing
>> sensitive file systems).
>
> the fundamental problem is that it becomes very difficult to
> implement fileservers which don't serve up regular files.
> you might make perminant changes to something stored on
> a disk with readahead.

 I'm not sure this problem is insurmountable. Some simple heuristics
along the lines of waiting a couple of Rreads to see if it looks like
an i/o pattern that is slurping up the whole file could go a long way.
However, I agree this is not the most reliable approach, and certainly
doesn't fit with the simplicity ideal.

> i'll admit that i don't understand the point of batching walks.
> i'm not sure why one would set up a case where you know you'll
> have a long network and where you know you'll need to execute
> a lot of walks.  most applications that do most i/o in a particular
> directory set . to that directory to avoid the walks.

 Right, but unless the mnt driver keeps an fid around for every file
in that directory set, every open is still two round trips - one to
walk to the file, and one to actually open it. Which is almost twice
as long as necessary. You might scoff at a single round trip, but as
someone who uses ircfs over the internet, I can tell you the
difference in responsiveness between echo and cat is noticeable
(though ok, echo has two extra round trips in this case).

> i'm not sure that octopus wouldn't be better off optimizing
> latency by running many more threads.  but that's just an ignorant
> opinion.

 How can multiple threads possibly help with latency caused by
operations that forced to be serial by the protocol? In fact, how can
multithreading help with latency in general? It will help
*throughput*, certainly, but unless you have a thread dedicated to
predicting the future, I can't see where the benifit will come from.
-sqweek



       reply	other threads:[~2008-09-18 13:34 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <0a44b94d5b9fa0b13dc1d9ae11472e5e@quanstro.net>
2008-09-18 13:34 ` sqweek [this message]
2008-09-18 13:49   ` Eric Van Hensbergen
2008-09-18 17:26     ` Francisco J Ballesteros
2008-09-18 20:05       ` Steve Simon
2008-09-18 20:38         ` Francisco J Ballesteros
2008-09-18 11:51 erik quanstrom
2008-09-18 13:34 ` Eric Van Hensbergen
  -- strict thread matches above, loose matches on Subject: below --
2008-09-18  9:57 sqweek
2008-09-18 10:36 ` Christian Kellermann
2008-09-18 10:48   ` Uriel
2008-09-27  1:17 ` Nathaniel W Filardo

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=140e7ec30809180634p393897b2r2bb7eed6cc8060ee@mail.gmail.com \
    --to=sqweek@gmail.com \
    --cc=9fans@9fans.net \
    --cc=quanstro@quanstro.net \
    /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;
as well as URLs for NNTP newsgroup(s).