From: Francis Moreau Date: Sun, 24 Dec 2006 09:36:16 GMT Subject: Re: [PATCH 0/17] Sliding window mmap for packfiles. Message-ID: <38b2ab8a0612240136r559376d4s14af3123f762a45d@mail.gmail.com> In-Reply-To: <20061224090508.GF7443@spearce.org> On 12/24/06, Shawn Pearce wrote: > Francis Moreau wrote: > > On 12/23/06, Shawn O. Pearce wrote: > > >This 17 patch series implements my much discussed, but never produced > > [snip] > > > > > >This series also permits accessing packfiles up to 4 GiB in size, > > >even on systems which permit only 2 GiB of virtual memory within > > >a single process (e.g. Windows and some older UNIXes). Of course > > > > Just out of curiosity, do you mean that there are some OS running on > > 32 bits machines which allow 4GiB size of virtual memory within a > > single process ? If so, could you give an example of such OS ? > > No. What I meant was the Git packfile/index format currently > supports up to 4 GiB of data in a single packfile. But *no* > OS using 32 bit virtual address space would permit us to access > that packfile prior to this series as we would have *no* memory > left for a stack, let alone for parsing commits, etc., as *all* > of the address space would have been dedicated to the packfile. > ok. > However with this series even a 32 bit OS which only permits > processes to have at most 2 GiB of address space (2 GiB split > between kernel space and userspace) can access packfiles up > to 4 GiB in size. That seems to be the split most OSes wind > up using, if they didn't push it out to 3.2 GiB like Linux > and Solaris have done. > Does it still needed for 64 bit OS ? if not, can the overhead (if there is a significant one) implied by your rework be avoid for such cases ? > This series is a good change because Git can now really make > full use of the space allowed by a single packfile. :-) > Yes I agree with you. -- Francis