This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Use single shared memory block pool for all pool allocators
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Andrew Pinski <pinskia at gmail dot com>
- Cc: Andi Kleen <andi at firstfloor dot org>, Mikhail Maltsev <maltsevm at gmail dot com>, gcc-patches mailing list <gcc-patches at gcc dot gnu dot org>, mliska <mliska at suse dot cz>, Jeff Law <law at redhat dot com>
- Date: Mon, 27 Jul 2015 11:13:01 +0200
- Subject: Re: [PATCH] Use single shared memory block pool for all pool allocators
- Authentication-results: sourceware.org; auth=none
- References: <55B51674 dot 4080203 at gmail dot com> <87y4i2rbxj dot fsf at tassilo dot jf dot intel dot com> <2378E38A-ACE5-47BB-8A45-BEE3F8486E49 at gmail dot com>
On Sun, Jul 26, 2015 at 9:09 PM, <pinskia@gmail.com> wrote:
>
>
>
>
>> On Jul 26, 2015, at 11:50 AM, Andi Kleen <andi@firstfloor.org> wrote:
>>
>> Mikhail Maltsev <maltsevm@gmail.com> writes:
>>
>>> Hi, all!
>>> Recently I did some profiling of GCC to find hotspots and areas of possible
>>> performance improvement among them. glibc malloc(3) is one of (perhaps
>>> known)
>>
>> I've been compiling gcc with tcmalloc to do a similar speedup. It would be
>> interesting to compare that to your patch.
>>
>> Another useful optimization is to adjust the allocation size to be >=
>> 2MB. Then modern Linux kernels often can give you a large page,
>> which cuts down TLB overhead. I did similar changes some time
>> ago for the garbage collector.
>
> Unless you are running with 64k pages which I do all the time on my armv8 system.
This can be a host configurable value of course.
But first of all (without looking at the patch but just reading the
description) this
sounds like a good idea. Maybe still allow pools to use their own backing if
the object size is larger than the block size of the caching pool?
Thanks,
Richard.
> Thanks,
> Andrew
>
>
>>
>> BTW I saw big differences in larger LTO builds.
>>
>> -Andi
>>
>> --
>> ak@linux.intel.com -- Speaking for myself only