On 8/14/07, Shawn O. Pearce <spearce@xxxxxxxxxxx> wrote: > Jon Smirl <jonsmirl@xxxxxxxxx> wrote: > One could probably argue that the defaults for 64b are too small; > perhaps they should be closer to 4G/24G seeing as how the 64b address > space is so huge that we're unlikely to run into issues with being > able to use >24G of virtual address at once. We've got 24,000GB of address space to play with. Why not set them 64G/512GB and forget about them for a decade? > > I haven't measured it but I suspect the OS calls for moving the > > windows are are quite slow on a relative basis since they have to > > rewrite a bunch of page tables. > > Maybe. Add a call to pack_report() at the end of the program you > are interested in and run it. We keep track of how often we move > windows around; you may find that we don't move them often enough > (or at all) to cause problems here. Or just run it under strace > and watch mmap() activity, filtering out the uninteresting bits. > > > Why is the window so small on 32b? I > > thought we were up to about a 1GB packfile before running out of > > address space with Mozilla. Shouldn't the window simply be set as > > large as possible on 32b, this size being a function of the available > > address space, not the amount of physical memory? > > Because programs need to malloc() stuff to work. And we need > stack space. And we need to let the runtime linker mmap() in the > shared libraries we are linked to. All in all we do get tight in > some 32b cases. The above defaults for 32b were chosen based on > the Linux kernel repository (its under 256M) and based on some > (crude) performance testing on Linux (which seemed to say the > 32M packedGitWindowSize wasn't really hurting us). They were > basically set to give us maximum address space for working heap > and yet not have a negative impact on one of our (at the time) > largest user groups. Kernel is barely under 256M. Do we need two limits, could we just start with the big one and assign first packfile fully to it, then start dividing it up dynamically as more pack files are opened? core.packedGitLimit core.packedGitWindowSize The real question is, what's the access pattern into the windows? If it is random then the windows get moved around continuously. If is it more or less sequential the windows will hardly get moved at all. Of course multi-threading the diff computation is going to do far more for me than playing with the window size. > In particular repack (aka git-pack-objects) is a real memory pig, > especially now with its various caches. The more address space we > can let it use in a 32b case the better off we probably are. > > If someone can show that increasing these 32b defaults is the > right thing to do even in very large repositories, *especially* > with something really brutal like `git-blame` on a very busy file or > `git repack -f -a` then please submit a patch to boost them. ;-) > > -- > Shawn. > -- Jon Smirl jonsmirl@xxxxxxxxx - 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
