From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 From: Venkatesh Srinivas Date: Sat, 7 Aug 2010 13:18:41 -0400 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=001636d349b9bed8b8048d3efa1c Subject: [9fans] Async clunk? Topicbox-Message-UUID: 4549fdb2-ead6-11e9-9d60-3106f5b1d025 --001636d349b9bed8b8048d3efa1c Content-Type: text/plain; charset=UTF-8 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 --001636d349b9bed8b8048d3efa1c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi,

At IWP9 4e, we suggested that asynchronous TClunks would do well= for 9p performance on moderate to high latency links; yesterday I came acr= oss a thread from 2006/01 on 9fans discussing asynchronous TClunks for othe= r 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
--001636d349b9bed8b8048d3efa1c-- From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <5a377994acef744dd4fd1e71bae22fe5@terzarima.net> From: Charles Forsyth Date: Sat, 7 Aug 2010 22:28:19 +0100 To: 9fans@9fans.net In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] Async clunk? Topicbox-Message-UUID: 45bac40c-ead6-11e9-9d60-3106f5b1d025 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <8f4c45be55eeb446160bc8dbf6dd1035@terzarima.net> From: Charles Forsyth Date: Sat, 7 Aug 2010 22:33:50 +0100 To: 9fans@9fans.net In-Reply-To: <5a377994acef744dd4fd1e71bae22fe5@terzarima.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] Async clunk? Topicbox-Message-UUID: 45c4bd9a-ead6-11e9-9d60-3106f5b1d025 >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 From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <8f4c45be55eeb446160bc8dbf6dd1035@terzarima.net> References: <5a377994acef744dd4fd1e71bae22fe5@terzarima.net> <8f4c45be55eeb446160bc8dbf6dd1035@terzarima.net> Date: Sun, 8 Aug 2010 13:56:00 +1000 Message-ID: From: Bruce Ellis To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [9fans] Async clunk? Topicbox-Message-UUID: 45fa3844-ead6-11e9-9d60-3106f5b1d025 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 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 > > From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <8f4c45be55eeb446160bc8dbf6dd1035@terzarima.net> References: <5a377994acef744dd4fd1e71bae22fe5@terzarima.net> <8f4c45be55eeb446160bc8dbf6dd1035@terzarima.net> From: Venkatesh Srinivas Date: Sun, 8 Aug 2010 02:18:02 -0400 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=0016364c79bdec5fe1048d49dd52 Subject: Re: [9fans] Async clunk? Topicbox-Message-UUID: 46048434-ead6-11e9-9d60-3106f5b1d025 --0016364c79bdec5fe1048d49dd52 Content-Type: text/plain; charset=UTF-8 On Sat, Aug 7, 2010 at 5:33 PM, Charles Forsyth 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 --0016364c79bdec5fe1048d49dd52 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 w= ait 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 t= he chan has CCACHE set (mount -C iirc). We already believe that the fileser= ver is 'decent' then...

-- vs
--0016364c79bdec5fe1048d49dd52-- From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <1abe810bdac3f7b8a36b0a5ac1fa5df5@terzarima.net> From: Charles Forsyth Date: Sun, 8 Aug 2010 08:04:24 +0100 To: 9fans@9fans.net In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] Async clunk? Topicbox-Message-UUID: 460a7880-ead6-11e9-9d60-3106f5b1d025 >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. From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <81eda0a0222900ff5f9d4eb825de8c47@terzarima.net> From: Charles Forsyth Date: Sun, 8 Aug 2010 08:10:47 +0100 To: 9fans@9fans.net In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] Async clunk? Topicbox-Message-UUID: 4613b9d6-ead6-11e9-9d60-3106f5b1d025 >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.) From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <1abe810bdac3f7b8a36b0a5ac1fa5df5@terzarima.net> References: <1abe810bdac3f7b8a36b0a5ac1fa5df5@terzarima.net> Date: Sun, 8 Aug 2010 17:13:41 +1000 Message-ID: From: Bruce Ellis To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [9fans] Async clunk? Topicbox-Message-UUID: 461c1ec8-ead6-11e9-9d60-3106f5b1d025 and it is ... On Sun, Aug 8, 2010 at 5:04 PM, Charles Forsyth 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. > > From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <81eda0a0222900ff5f9d4eb825de8c47@terzarima.net> References: <81eda0a0222900ff5f9d4eb825de8c47@terzarima.net> From: Venkatesh Srinivas Date: Sun, 8 Aug 2010 10:17:02 -0400 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=0016364c7e23f7d6c2048d508e4f Subject: Re: [9fans] Async clunk? Topicbox-Message-UUID: 4621bb76-ead6-11e9-9d60-3106f5b1d025 --0016364c7e23f7d6c2048d508e4f Content-Type: text/plain; charset=UTF-8 On Sun, Aug 8, 2010 at 3:10 AM, Charles Forsyth 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 --0016364c7e23f7d6c2048d508e4f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sun, Aug 8, 2010 at 3:10 AM, Charles Forsyth = <forsyth@terz= arima.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 ope= n, (read|write), close
into a single operation.=C2=A0

When we tried= out async Clunk in the Journal Callbacks work, it offered some fairly grea= t improvements; and the details that it varies in are very minor compared t= o 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.=C2=A0

>=C2=A0services that wait for a close to commit,

Hmm. Does this mean that any modification to devmnt, to keep a l= arger pool of FDs active for example, rather than clunking eagerly while wa= lking, is unsafe? That would hold around directory FDs, which would make se= rvices like the above unhappy, or at least behave differently. Perhaps thos= e file servers are assuming something not specified in the 9p definitions?<= /span>

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

-- vs

--0016364c7e23f7d6c2048d508e4f-- From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <81eda0a0222900ff5f9d4eb825de8c47@terzarima.net> Date: Mon, 9 Aug 2010 03:02:18 +1000 Message-ID: From: Bruce Ellis To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] Async clunk? Topicbox-Message-UUID: 46278d58-ead6-11e9-9d60-3106f5b1d025 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 wrote: > On Sun, Aug 8, 2010 at 3:10 AM, Charles Forsyth > 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 s= ome > fairly great improvements; and the details that it varies in are very min= or > compared to uncached 9p, particularly for decent fileservers. > Since Clunk cannot fail, this also admits a simple (perhaps) approximatio= n - > issue the clunk as expected, but do not wait for RClunk. >>=A0services that wait for a close to commit, > Hmm. Does this mean that any modification to devmnt, to keep a larger poo= l > of FDs active for example, rather than clunking eagerly while walking, is > unsafe? That would hold around directory FDs, which would make services l= ike > 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 > >