From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1077) From: Eric Van Hensbergen In-Reply-To: <83c63c25-5d91-4bc1-910d-4e8402ccda40@g28g2000yqh.googlegroups.com> Date: Wed, 10 Feb 2010 10:28:30 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <76824f16-1f1c-484a-a3f8-e73f7f568845@36g2000yqu.googlegroups.com> <83c63c25-5d91-4bc1-910d-4e8402ccda40@g28g2000yqh.googlegroups.com> To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Subject: Re: [9fans] Speed of 9pfuse on Linux Topicbox-Message-UUID: d2506a62-ead5-11e9-9d60-3106f5b1d025 On Feb 10, 2010, at 7:32 AM, Pavel Klinkovsky wrote: >> 1) real plan9 to the same place >> 2) qemu plan9 on Fedora to the same place > As I wrote above, I made exactly the same test on exactly the same HW > (and internet connection). > 1. Native Plan9. > 2. Native Fedora 10 with p9p. >=20 >> "It's slow, what's wrong" is perhaps a little vague. > Not precisely measured (I can do it today). > My estimation of the time spent by 'ls' command in contrib directory: > - 9pfuse on Fedora was more than 10 times slower. >=20 That's actually probably pretty good, if you look at slide 10 & 11 on = my Linux 9P Trace and Walkthrough (top of http://www.graverobber.org at = the moment) you'll see the bad protocol behavior caused by v9fs at the = moment -- 9pfuse probably has around the same order increase. The = problem is that Linux doesn't know we got all the attribute information = with the dirread, and then goes and individually queries each file in = the directory with a stat -- this happens in a serial fashion, so the = high latency to sources just makes the problem worse. A potential solution is to cache metadata, which would speed things up = dramatically for static data, but might mess things up for synthetic = files. -eric