On 12/24/06, Shawn Pearce <spearce@spearce.org> wrote:
quoted text
> 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.

quoted text
> 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 ?

quoted text
> 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
-
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