[9fans] Async clunk?

[9fans] Async clunk?

[Venkatesh Srinivas]

[-- Attachment #1: Type: text/plain, Size: 426 bytes --]

Hi,

At IWP9 4e, we suggested that asynchronous TClunks would do well for 9p
performance on moderate to high latency links; yesterday I came across a
thread from 2006/01 on 9fans discussing asynchronous TClunks for other
reasons ('clunk clunk' is the title; http://9fans.net/archive/2006/01/105).

Did anyone do any further work along this? As far as I can see, cclose()
does a synchronous clunk...

Thanks,
-- vs

[-- Attachment #2: Type: text/html, Size: 515 bytes --]

Re: [9fans] Async clunk?

[Charles Forsyth]

close must be synchronous, unless you aim for NFS semantics.
plan 9 will hand the work to a service process [only] when a process is interrupted by a note
during a closefgrp (eg, when a file-group is closed when a process exits), to allow
deadlocks to be broken (by a note), or to compensate for dead servers, not to improve latency.

Re: [9fans] Async clunk?

[Charles Forsyth]

>close must be synchronous, unless you aim for NFS semantics.

to be more explicit: think of exclusive-use services, services that wait for a close to commit,
files with DMEXCL, and files opened ORCLOSE

Re: [9fans] Async clunk?

[Bruce Ellis]

I can't completely agree with this. I'd like to presrve Clunk
semantics but it leads to all sorts of deadlocks. That's why "slay"
was introduced, and "closefiles" (or whatever it's called).

Research Inferno has ha async clunks on 'M' for 15 years with no
problems, just no deadlocks.

Think about it a bit.

brucee

On Sun, Aug 8, 2010 at 7:33 AM, Charles Forsyth <forsyth@terzarima.net> wrote:
>>close must be synchronous, unless you aim for NFS semantics.
>
> to be more explicit: think of exclusive-use services, services that wait for a close to commit,
> files with DMEXCL, and files opened ORCLOSE
>
>

Re: [9fans] Async clunk?

[Charles Forsyth]

>Research Inferno has ha async clunks on 'M' for 15 years with no
>problems, just no deadlocks.
>Think about it a bit.

there is a simple and obvious test program that fails unpredictably under that regime
but works in the other systems, and would be expected to work.

Re: [9fans] Async clunk?

[Bruce Ellis]

and it is ...

On Sun, Aug 8, 2010 at 5:04 PM, Charles Forsyth <forsyth@terzarima.net> wrote:
>>Research Inferno has ha async clunks on 'M' for 15 years with no
>>problems, just no deadlocks.
>>Think about it a bit.
>
> there is a simple and obvious test program that fails unpredictably under that regime
> but works in the other systems, and would be expected to work.
>
>

Re: [9fans] Async clunk?

[Venkatesh Srinivas]

[-- Attachment #1: Type: text/plain, Size: 533 bytes --]

On Sat, Aug 7, 2010 at 5:33 PM, Charles Forsyth <forsyth@terzarima.net>wrote:

> >close must be synchronous, unless you aim for NFS semantics.
>
> to be more explicit: think of exclusive-use services, services that wait
> for a close to commit,
> files with DMEXCL, and files opened ORCLOSE
>

For DMEXCL and ORCLOSE, we'd always issue synchronously.

Perhaps we could turn on async clunk for other files when the chan has
CCACHE set (mount -C iirc). We already believe that the fileserver is
'decent' then...

-- vs

[-- Attachment #2: Type: text/html, Size: 892 bytes --]

Re: [9fans] Async clunk?

[Charles Forsyth]

>Perhaps we could turn on async clunk for other files when the chan has
>CCACHE set (mount -C iirc). We already believe that the fileserver is
>'decent' then...

that's more plausible, since you've declared that you're not interested
in certain details, but then the larger question arises: why pick on clunk?
in Op, the thing that reduces network latency is combining the sequence open, (read|write), close
into a single operation. (for brucee's case, the CCACHE check wouldn't be sufficient:
it needs to be the other ones as well.)

Re: [9fans] Async clunk?

[Venkatesh Srinivas]

[-- Attachment #1: Type: text/plain, Size: 1517 bytes --]

On Sun, Aug 8, 2010 at 3:10 AM, Charles Forsyth <forsyth@terzarima.net>wrote:

> >Perhaps we could turn on async clunk for other files when the chan has
> >CCACHE set (mount -C iirc). We already believe that the fileserver is
> >'decent' then...
>
> that's more plausible, since you've declared that you're not interested
> in certain details, but then the larger question arises: why pick on clunk?
> in Op, the thing that reduces network latency is combining the sequence
> open, (read|write), close
> into a single operation.
>

When we tried out async Clunk in the Journal Callbacks work, it offered some
fairly great improvements; and the details that it varies in are very minor
compared to uncached 9p, particularly for decent fileservers.

Since Clunk cannot fail, this also admits a simple (perhaps) approximation -
issue the clunk as expected, but do not wait for RClunk.

> services that wait for a close to commit,

Hmm. Does this mean that any modification to devmnt, to keep a larger pool
of FDs active for example, rather than clunking eagerly while walking, is
unsafe? That would hold around directory FDs, which would make services like
the above unhappy, or at least behave differently. Perhaps those file
servers are assuming something not specified in the 9p definitions?

Also, cyclic structures in Limbo with file descriptors embedded will not
release the FD immediately after the outer structure is discarded. In a
sense, that is also a delayed Clunk...

-- vs

[-- Attachment #2: Type: text/html, Size: 2954 bytes --]

Re: [9fans] Async clunk?

[Bruce Ellis]

trust me - experiment. ask questions. i'll send code. it can be an
enormous speedup.

brucee

On Mon, Aug 9, 2010 at 12:17 AM, Venkatesh Srinivas <me@acm.jhu.edu> wrote:
> On Sun, Aug 8, 2010 at 3:10 AM, Charles Forsyth <forsyth@terzarima.net>
> wrote:
>>
>> >Perhaps we could turn on async clunk for other files when the chan has
>> >CCACHE set (mount -C iirc). We already believe that the fileserver is
>> >'decent' then...
>>
>> that's more plausible, since you've declared that you're not interested
>> in certain details, but then the larger question arises: why pick on
>> clunk?
>> in Op, the thing that reduces network latency is combining the sequence
>> open, (read|write), close
>> into a single operation.
>
> When we tried out async Clunk in the Journal Callbacks work, it offered some
> fairly great improvements; and the details that it varies in are very minor
> compared to uncached 9p, particularly for decent fileservers.
> Since Clunk cannot fail, this also admits a simple (perhaps) approximation -
> issue the clunk as expected, but do not wait for RClunk.
>> services that wait for a close to commit,
> Hmm. Does this mean that any modification to devmnt, to keep a larger pool
> of FDs active for example, rather than clunking eagerly while walking, is
> unsafe? That would hold around directory FDs, which would make services like
> the above unhappy, or at least behave differently. Perhaps those file
> servers are assuming something not specified in the 9p definitions?
> Also, cyclic structures in Limbo with file descriptors embedded will not
> release the FD immediately after the outer structure is discarded. In a
> sense, that is also a delayed Clunk...
> -- vs
>
>