[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] tla library-add - high cpu

From: Tom Lord
Subject: Re: [Gnu-arch-users] tla library-add - high cpu
Date: Fri, 5 Sep 2003 09:40:45 -0700 (PDT)

    > From: Andrew Suffield <address@hidden>

    > On Fri, Sep 05, 2003 at 08:40:15AM +1000, Robert Collins wrote:
    > >         tla library-add seems to spend most of it's time thinking, not 
    > > or retrieving.=20

    > > For instance, in a recent tla library-add
    > > address@hidden/squid--HEAD--3.0 (~400 patches), into a
    > > clean revision library, tla took ~15 seconds to get back to the start
    > > and do the first patch. After that though, it spends quite some time
    > > doing nothing obvious, and top shows tla at 100% cpu.

    > > The archive was being accessed via sftp. It's possibly a retrieval code
    > > problem - or a logic problem of some sort. It's spending 30-40 seconds
    > > per patch, and those patches can be grabbed by sftp in about 2 seconds,
    > > so I suspect a bad O somewhere in tla itself.

    > I believe it's actually a wait-for-ack problem - library-add
    > repeatedly fires off a request, and sits waiting for a response,
    > instead of pipelining. So latency kills you.

Nope -- at least not if this is the problem we fixed on IRC the other

Rob is running on a 64-bit machine.  Patching is a fairly
regexp-intensive operation (due to computing inventories -- those
=tagging-method regexps).  The default DFA and NFA cache sizes of Rx
is measured in bytes -- but allocated in multiples of the machine's
word-size.  So, in effect, the cache size was cut in half on a 64 bit
machine.  Word has it that just bumping the cache size fixed the

(It's not impossible I've got the context wrong in the cross traffic
between IRC and the list, of course.)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]