Re: [9fans] A little more ado about async Tclunk

[Bruce Ellis <bruce.ellis@gmail.com>]

I explained to VS that Research Inferno has been doing it for 10 years.

A much simpler approach. Solves your problems. Sorry that
wing-commander can't package it for today.

brucee

On Wed, Oct 27, 2010 at 3:23 PM, erik quanstrom <quanstro@quanstro.net> wrote:
>> I just committed a very simple implementation of asynchronous TClunk to
>> inferno-npe. The implementation will only defer sending clunks when MCACHE
>> is specified on the mount (via the new -j option to Inferno's mount,
>> analogous to Plan 9's mount -C) and when the file is not marked ORCLOSE. The
>> implementation is very simple -- I queue the RPCs devmnt would issue
>> synchronously and send them from a single kproc, one-after-another. There is
>> no attempt to overlap the TClunks. There is no logic to handle flushing a
>> deferred clunks on an unmount yet. The diff is not as clean as I would like,
>> but it works.
>
> how do you flow control the clunking processes?  are you using
> qio?  if so, what's the size of the buffer?
>
> also, do you have any test results for different latentices?  how
> about a local network with ~0.5ms rtt and a long distance connection
> at ~150ms?
>
> have you tried this in user space?  one could imagine passing the
> fds to a seperate proc that does the closes without involving the kernel.
>
> - erik
>
>