On Mon, Sep 10, 2007 at 12:05:30AM -0400, Nicolas Pitre wrote: > This follows the threaded delta patches already posted and currently > available in the pu branch. I think this should round up the topic for > now, at least to be moved to 'next'. I'll let someone else find the > right recipee to automatically detect pthread availability, etc. Also > people with SMP machines please give it a try. Looks like Junio has already merged the initial patch into 'next'. Here are a few numbers for repacking linux-2.6 (git-repack -a -d -f) on a 4-way 2Ghz Opteron with 6G of RAM. Stock 'next': real 3m48.172s user 3m42.678s sys 0m3.516s 'next' with THREADED_DELTA_SEARCH=1 real 2m18.028s user 3m32.709s sys 0m6.044s Interestingly, about 55 seconds of that was in the _writing_ phase (this seems a bit slow to me, but unfortunately I don't know anything about the disk characteristics; it looks like JFS on top of a big hardware RAID). But subtracting that out from each, we get a nice 2x speedup for the rest of the process. this series, --threads=1 real 3m44.804s user 3m36.198s sys 0m4.164s Slightly more system time than stock next, but we come out ahead on the user time...I'm not sure why. this series, --threads=4 real 1m54.619s user 3m33.745s sys 0m6.356s Again the writing phase is long, but if we subtract it out, we are looking at about 2.6x speedup (we are still getting some single-threaded time counting the objects (about 20 seconds, I think). this series, --threads=8 I get a segfault very early in the deltification process, but I haven't been able to track it very far. gdb reports it at varying locations in the code, and I don't have valgrind or electric fence available at the moment to get a more accurate idea of the cause. I might be able to look at it more later. -Peff - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
