Re: [PATCH 0/17] Sliding window mmap for packfiles.
- From
- Francis Moreau <francis.moro@gmail.com>
- Date
- Dec 24, 2006, 09:36 UTC
- Message-ID
- <38b2ab8a0612240136r559376d4s14af3123f762a45d@mail.gmail.com>
- In-Reply-To
- <20061224090508.GF7443@spearce.org>
On 12/24/06, Shawn Pearce <spearce@spearce.org> wrote:
Show 20 quoted lines
> Francis Moreau <francis.moro@gmail.com> wrote: > > On 12/23/06, Shawn O. Pearce <spearce@spearce.org> 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.
Show 7 quoted lines
> 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