Patch: Increase GGC_QUIRE_SIZE
Matt Austern
austern@apple.com
Mon Sep 27 10:46:00 GMT 2004
On Sep 26, 2004, at 7:31 PM, Daniel Jacobowitz wrote:
> On Sun, Sep 26, 2004 at 06:23:06PM -0700, Matt Austern wrote:
>> When the memory allocator uses mmap to request memory from the kernel,
>> it asks for GGC_QUIRE_SIZE pages at a time. GGC_QUIRE_SIZE could in
>> principle be 1; it's set to a larger value for the sake of
>> performance.
>> In the current compiler it's 16.
>>
>> 16 is still a pretty tiny number; with the usual 4K pages it means
>> we're asking for 64K at a time, and 64K doesn't go very far these
>> days.
>> This patch raises it to 256, meaning we'll typically be allocating
>> memory in 1MB chunks. This helps performance in two ways. First,
>> it's
>> fewer calls to mmap. Second, kernels are happier dealing with a few
>> large chunks than with many small ones. On Darwin, this patch
>> improves
>> compilation speed by about 2%; most of the reduction is in system
>> time.
>>
>> OK to commit to mainline?
>
> I do have one concern - what's the largest page size we actually
> encounter? Is allocating 16MB with 64K pages going to be OK
> everywhere?
I don't have a proof, but I'm pretty sure the answer is yes. I
thought about this for a while, and I couldn't come up with any
scenario where this would cause a problem on a realistic host. If we
do find one, then we can override it for that host only.
(In case you're wondering why I chose 256, instead of 4096 or 8192 or
something... Yes, I wanted to be conservative. I stopped seeing major
performance improvements when I increased it past 256. I never found a
value so large that it caused problems, though.)
--Matt
More information about the Gcc-patches
mailing list