From mboxrd@z Thu Jan  1 00:00:00 1970
References: <E1648EE5-10AB-4933-9125-D5BF01CF6CEF@ar.aichi-u.ac.jp>
	<CAFSF3XOQY2rH2fRmFEV2d5vGbc6ONkVpRvKY=dR7AvorqB7aKA@mail.gmail.com>
	<DC50FC0A-0449-4E45-BDCD-A0065B17908B@ar.aichi-u.ac.jp>
From: Kenny Lasse Hoff Levinsen <kennylevinsen@gmail.com>
Content-Type: text/plain;
	charset=us-ascii
In-Reply-To: <DC50FC0A-0449-4E45-BDCD-A0065B17908B@ar.aichi-u.ac.jp>
Message-Id: <D58680F1-C61E-492B-9414-FDECD31708DE@gmail.com>
Date: Wed, 11 May 2016 15:44:36 +0200
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)
Subject: Re: [9fans] cpu command latency
Topicbox-Message-UUID: 8ebe004e-ead9-11e9-9d60-3106f5b1d025

Your loop only seems to dials the server once, then reuses the channel from /=
srv. 9fs(4) is just a convenience wrapper for common hosts and tasks that ul=
timately calls srv(4) and mount(1) as necessary - if the channel exists, it i=
s simply a call to mount(1), which translates to an attach(5) 9P message on t=
he existing connection.

Delete the channel from /srv in the loop to test a full remote mount dance, i=
ncluding the initial dial. It shouldn't take 3s to dial, though.

Best regards,
Kenny Levinsen

> On 11. maj 2016, at 15.12, arisawa <arisawa@ar.aichi-u.ac.jp> wrote:
>=20
> thanks charles for your quick response.
>=20
> the times below are mount latency just after rebooting.
> the first is much larger than others.
> 0.00u 0.00s 3.73r     9fs sources
> 0.00u 0.00s 0.71r     9fs sources
> 0.00u 0.00s 0.21r     9fs sources
> with the script below:
> for(i in 1 2 3){
>        time 9fs $host
>        unmount /n/$host
>        sleep 3
>    }
> }
>=20
> probably cpu command latency will show similar behavior with much more tim=
e.
>=20
> Kenji Arisawa
>=20
>=20