Re: Surprising use of memory and time when repacking mozilla's gecko repository

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

 



On Fri, Jul 05, 2019 at 01:09:55AM -0400, Jeff King wrote:
> On Thu, Jul 04, 2019 at 07:05:30PM +0900, Mike Hommey wrote:
> > Finally, with 1 thread, the picture changes greatly. The overall process
> > takes 2.5h:
> > - 50 seconds enumerating and counting objects.
> > - ~2.5h compressing objects.
> > - 3 minutes and 25 seconds writing objects!
> 
> That's weird. I'd expect us to find similar amounts of deltas, but we
> don't have the writing slow-down. I wonder if there is some bad
> interaction between the multi-threaded code and the delta cache.
> 
> Did you run the second, single-thread run against the exact same
> original repository you had? Or did you re-run it on the result of the
> multi-thread run? Another explanation is that the original repository
> had some poor patterns that made objects expensive to access (say, a ton
> of really deep delta chains). And so the difference between the two runs
> was not the threads, but just the on-disk repository state.
> 
> Kind of a long shot, but if that is what happened, try running another
> multi-threaded "repack -f" and see if its writing phase is faster.

I've run 36-threads, 16-threads and 1-thread in sequence on the same
repo, so 16-threads was repacking what was repacked by the 36-threads,
and 1-thread was repacking what was repacked by the 16-threads. I
assumed it didn't matter, but come to think of it, I guess it can.

Mike



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux