Jeff King <peff@xxxxxxxx> writes: > On Tue, Apr 17, 2012 at 03:17:28PM -0700, Junio C Hamano wrote: > >> > How many cores are there on this box? Have you tried setting >> > pack.windowMemory to (12 / # of cores) or thereabouts? >> >> Hrm, from the end-user's point of view, it appears that pack.windowMemory >> ought to mean the total without having to worry about the division of it >> across threads (which the implementation should be responsible for). > > Agreed. I had to look in the code to check which it meant. I'm not sure > we can change it without regressing existing users, though. This is a tangent, but I noticed that the canned settings for "aggressive" use an arbitrarily hardcoded value of depth=250 and window=250 (tweakable with gc.aggressiveWindow). Even though a shallower depth does cause base candidates with too long a chain hanging to be evicted prematurely while it is still in window and will lead to smaller memory consumption, I do not think the value of "depth" affects the pack-time memory consumption too much. But the runtime performance of the resulting pack may not be great (in the worst case you would have to undelta 249 times to get to the object data). We may want to loosen it a bit. Also it might make sense to make the window size a bit more flexible depending on the nature of your history (you would get bigger benefit with larger window when your history has fine grained commits; if there are not many few-liner commits, larger window may not help you that much). -- 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