author | Shawn O. Pearce <spearce@spearce.org> | |
Sun, 27 Aug 2006 09:53:48 +0000 (05:53 -0400) | ||
committer | Shawn O. Pearce <spearce@spearce.org> | |
Sun, 14 Jan 2007 07:15:08 +0000 (02:15 -0500) | ||
commit | 53dbce78a2a018bd2828d3ecc4123015f88ae36f | |
tree | 53c96371e3b859732d5582952320ebf75056c8e9 | tree | snapshot |
parent | 35ef237cf630418c2e45752eb527268693a2895b | commit | diff |
Map only part of the generated pack file at any point in time.
When generating a very large pack file (for example close to 1 GB
in size) it may be impossible for the kernel to find a contiguous
free range within a 32 bit address space for the mapping to be
located at. This is especially problematic on large imports where
there is a lot of malloc activity occuring within the same process
and the malloc'd regions may straddle the previously mapped regions,
thereby creating large holes in the address space.
So instead we map only 128 MB of the pack at any given time.
This will likely increase the number of times the file gets mapped
(with additional system time required to update the page tables
more frequently) but will allow the program to handle packs up to
4 GB in size.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When generating a very large pack file (for example close to 1 GB
in size) it may be impossible for the kernel to find a contiguous
free range within a 32 bit address space for the mapping to be
located at. This is especially problematic on large imports where
there is a lot of malloc activity occuring within the same process
and the malloc'd regions may straddle the previously mapped regions,
thereby creating large holes in the address space.
So instead we map only 128 MB of the pack at any given time.
This will likely increase the number of times the file gets mapped
(with additional system time required to update the page tables
more frequently) but will allow the program to handle packs up to
4 GB in size.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
fast-import.c | diff | blob | history |