On Aug 11, 2008, at 15:10, Andi Kleen wrote:
> As a quick workaround you could try it with a 32bit git executable?

quoted text
> (assuming you have a distribution with proper multilib support)

>

> I think the right fix would be to make git throttle itself (not

> use mmap, use very small defaults etc.) on low memory systems.

> It could take a look a /proc/meminfo for this.

I've always felt that keeping largish objects (say anything >1MB)

loose makes perfect sense. These objects are accessed infrequently,

often binary or otherwise poor candidates for the delta algorithm.
Many repositories are mostly well-behaved with large number of text

files that aren't overly large and compress/diff well. However, often

a few huge files creep in. These might be a 30 MB Word or PDF documents

(with lots of images of course), a bunch of artwork, some random .tgz

files

with required tools or otherwise.
Regardless of their origin, the presence of such files in real-world

SCMs

is a given and can ruin performance, even if they're hardly ever

accessed

or updated. If we would leave such oddball objects loose, the pack would

be much smaller, easier to generate, faster to use and there should be

no

memory usage issues.
   -Geert

--

To unsubscribe from this list: send the line "unsubscribe git" in

the body of a message to majordomo@vger.kernel.org

More majordomo info at  http://vger.kernel.org/majordomo-info.html