Re: git-revert is a memory hog

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Jan 29, 2008, 21:51 UTC
Message-ID: <alpine.LFD.1.00.0801300844170.28476@www.l.google.com>
In-Reply-To: <20080128055933.GA13521@coredump.intra.peff.net>

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