| commit | e8b7c6129e3b158a97c39a3213a58b40eb47f1b4 | |
| author | ak <ak@138bc75d-0d04-0410-961f-82ee72b054a4> | |
| Sat, 29 Oct 2011 01:01:54 +0000 (29 01:01 +0000) | ||
| committer | ak <ak@138bc75d-0d04-0410-961f-82ee72b054a4> | |
| Sat, 29 Oct 2011 01:01:54 +0000 (29 01:01 +0000) | ||
| tree | 2071cd9a9389dac958320f1bd9ae2bb9c110cc2b | treesnapshot (tar.gz zip) |
| parent | 76f0411d965454c0b994b5d5c0728771e04b3c35 | commitdiff |
Free large chunks in ggc v2
This implements the freeing back of large chunks in the ggc madvise path
Richard Guenther asked for. This way on systems with limited
address space malloc() and other allocators still have
a chance to get back at some of the memory ggc freed. The
fragmented pages are still just given back, but the address space
stays allocated.
I tried freeing only aligned 2MB areas to optimize for 2MB huge
pages, but the hit rate was quite low, so I switched to 1MB+
unaligned areas.
v2: Hardcode free unit size instead of param
gcc/:
2011-10-18 Andi Kleen <ak@linux.intel.com>
* ggc-page (release_pages): First free large continuous
chunks in the madvise path.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@180648 138bc75d-0d04-0410-961f-82ee72b054a4
This implements the freeing back of large chunks in the ggc madvise path
Richard Guenther asked for. This way on systems with limited
address space malloc() and other allocators still have
a chance to get back at some of the memory ggc freed. The
fragmented pages are still just given back, but the address space
stays allocated.
I tried freeing only aligned 2MB areas to optimize for 2MB huge
pages, but the hit rate was quite low, so I switched to 1MB+
unaligned areas.
v2: Hardcode free unit size instead of param
gcc/:
2011-10-18 Andi Kleen <ak@linux.intel.com>
* ggc-page (release_pages): First free large continuous
chunks in the madvise path.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@180648 138bc75d-0d04-0410-961f-82ee72b054a4
| gcc/ChangeLog | diffblobblamehistory | |
| gcc/ggc-page.c | diffblobblamehistory |