On Mon, 28 Jan 2008, Jeff King wrote: > > I tried to reproduce this, but my peak heap allocation was only around > 20MB. Is your repository fully packed? Not packed at all? Can you use > valgrind/massif to figure out where the memory is going? I definitely can reproduce it, it's horrid. This is from "top" fairly late in the game, but with the thing not even done yet. Current git, pretty much fully (and fairly aggressively) packed current kernel repo, and using "diff.renamelmit=0". 4751 torvalds 20 0 852m 446m 47m R 72 22.4 2:46.58 git-merge-recur It finally finished with time reporting: 208.15user 3.50system 4:01.50elapsed 87%CPU (0avgtext+0avgdata 0maxresident)k 238736inputs+4544outputs (8261major+280971minor)pagefaults 0swaps where those 280971 minor page faults are what largely indicates how much memory it used (the technical term for that number is "metric buttload of memory"). But I'm in Melbourne right now on my laptop,and probably won't be able to debug this much. > In your case, the patch doesn't apply cleanly, so we end up doing a > 3-way merge (in my tests, it is git-merge-recursive which ends up taking > up the memory). It is indeed git-merge-recursive. It just shouldn't take that much memory. Linus - 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
