On Aug 2, 2010, at 5:35 PM, Eric Kow wrote: > Thanks for the details, > > On Mon, Aug 02, 2010 at 16:41:38 +0200, Florian Gilcher wrote: >>> I had dumbly plugged in "4474726631771 nanoseconds in minutes" into >>> Google's converter tool but missed a digit. With the new 74 minute >>> number, that can't mean what I assumed it meant. Then what do these >>> times correspond to? >> >> Well, the call times can be way beyond the runtime. It is the sum >> of the delta between all function entry timestamps and their corresponding >> exit. >> So, 4 threads entering __semwait_signal and waiting for 10 minutes would >> cause the sum to be 40 minutes. > > Is there a way to get something that looks more like the runtime?
dtrace is pretty much a programming language in itself. So, you can for example emit any kind of log you want, like maintaining a counter how many __semwaits are active at one given moment. I am no expert in it, though. Instruments is good at having a "live" look at the system, if you know how to configure it. >> Well, the good question that mornfall raised in the IRC channel is whether >> Darcs is at fault here or just the victim of a fight of some IO layer vs. the >> operating system. > > There's also this comment by Jason: > | I have a hunch that __semwait_signal is very low level. Low enough that it > | might be where the darcs process blocks when waiting for disk IO. If that's > | true then I would consider long times there a symptom not a cause. > > So how can we chip away at the problem? > > * Is testing darcs -f-mmap useful? Maybe it could at least give us a > simpler Darcs to play with? I tested with and without mmap. Not much of a difference, except for some missing mmaps. Mmap is said to be rather slow for small files on OS X but "rather slow" is something like 50% and I don't know what "small" means. I might dig, if I have the time, but I do not, at the moment. > * Perhaps produce a cut down version of Darcs that only knows how to > locally darcs get a repository? Perhaps we can keep simplifying this > until it's a small self-contained artificial tester. > > * Perhaps produce an artificial version of the GHC repository, with > the same number of files, and the same number of patches but all > nearly empty? > > What else can we do to gain insight? > > Thanks! I think it would be interesting to have a binary that basically does all the patch copying a get would do. I think it might be worthwhile to check out the GHC dtrace probes first. >>> [1] And if you happen to be in an undergraduate university setting >>> taking a similar class <http://www.seas.upenn.edu/~cse381/>, pay >>> more attention! It seems 1998-Eric's effort was woefully inadequate. >> >> Thanks, too late as well. > > :-) That wistful note was actually addressed to darcs-users as a whole > But maybe we're all relatively old and grumpy. Yes, but in my case, the note hit spot-on ;). _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
