From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <87C61423-7C13-4516-88B5-C2ABA7D32AA9@me.com> Date: Tue, 5 May 2015 23:23:31 +0100 Message-ID: From: Charles Forsyth To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=047d7b624e88e177cd05155d20a4 Subject: Re: [9fans] fossil+venti performance question Topicbox-Message-UUID: 4f0da5d0-ead9-11e9-9d60-3106f5b1d025 --047d7b624e88e177cd05155d20a4 Content-Type: text/plain; charset=UTF-8 On 5 May 2015 at 16:38, David du Colombier <0intro@gmail.com> wrote: > > How many times do you time it on each machine? > > Maybe ten times. The results are always the same ~5%. > Also, I restarted vacfs between each try. It was the effect of the ram caches that prompted the question. My experience is similar to Steve's: it was faster, and now it's initially very very slow. I looked at changes from that version of venti to this, and I didn't see anything that would cause that. (The problem could be outside venti, but I looked at some possibly relevant kernel changes too.) Note that the raw drive speed on my venti machine is fine (no doubt it could be better, but it's fine). I convinced myself through experiments that the problem was with venti, not fossil. I used some debugging code in venti and had the impression that it took a surprisingly long time to handle each request: that the time was in venti. The effect was similar to that of a lost interrupt for a device driver. I used ratrace on it, but didn't spot an obvious culprit. I was tempted to rip out or disable the drive scheduling code in venti to see what happened, but not for the first time I ran out of time and had to get back to some other work. One thing I didn't know was that the results were different when fossil was on a different machine. I thought I'd tried that with vacfs myself, but apparently not or mine was as slow as when on the same machine. --047d7b624e88e177cd05155d20a4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On 5 May 2015 at 16:38, David du Colombier <0intro@gmail.com>= wrote:
> How many ti= mes do you time it on each machine?

Maybe ten times. The results are always the same ~5%.
Also, I restarted vacfs between each try.

It was the = effect of the ram caches that prompted the question.

My experience is similar to = Steve's: it was faster, and now it's initially very very slow.
I looked at changes from that version of venti = to this, and I didn't see anything that would cause that.
(The problem could be outside venti, but I looked at som= e possibly relevant kernel changes too.)
Note that the raw drive speed on my vent= i machine is fine (no doubt it could be better, but it's fine).
I convinced myself through experiments that the pr= oblem was with venti, not fossil.
I used so= me debugging code in venti and had the impression that it took a surprising= ly long time
to handle each request: that t= he time was in venti. The effect was similar to that of a lost
interrupt for a device driver. I used ratrace on it, bu= t didn't spot an obvious culprit.
I was= tempted to rip out or disable the drive scheduling code in venti to see wh= at happened, but
not for the first time I r= an out of time and had to get back to some other work.

One thing I didn't kno= w was that the results were different when fossil was on a different machin= e.
I thought I'd tried that with vacfs = myself, but apparently not or mine was as slow as when on the same
machine.
--047d7b624e88e177cd05155d20a4--