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