This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 1/5] Use MADV_DONTNEED for freeing in garbage collector


On Mon, Oct 10, 2011 at 01:11:13PM +0200, Richard Guenther wrote:
> > I don't see why. ?MADV_DONTNEED isn't perfect, what it does (on Linux)
> > is that it zaps the whole page range, which essentially brings it into
> > the exact same state as immediately after mmap. ?Any touch of the
> > pages will result in a zeroed page being inserted into the page tables.
> 
> Which means we save the zeroing when allocating non-MADV_DONTNEEDed
> pages first.  And will be eventually able to unmap zapped pages.

Well, there are 3 kind of pages in G.free_pages list after the patch.
1) pages added by alloc_page (GGC_QUIRK_SIZE - 1 pages each time, for p->bytes ==  G.pagesize only)
2) pages on which free_page has been called during last ggc_collect's sweep_pages
3) MADV_DONTNEED hinted pages from release_pages

Pages of 1) and 3) category have the same cost, pages of 2) category are
cheaper to access.  Pages of the 3) category are guaranteed to be at the
end of list (simply because free_pages marks all pages in the G.free_pages
list).  So this patch doesn't make things worse than it was before in this
regard, though maybe we should munmap p->bytes != G.pagesize pages right
away in release_pages instead of MADV_DONTNEED marking them.  They are
rarely to be reused.  For p->bytes == G.pagesize pages (the vast majority)
on the other side 1) shouldn't be really added until there are no 2) and 3)
category pages.

> > Not just that. ?MADV_DONTNEED needs to flush the dirty pages from the page
> > tables and when they are touched again, they need to be cleared (or
> > pre-cleared pages inserted). ?So, while MADV_DONTNEED is less expensive than
> > munmap + mmap, it is still not free.
> 
> But it's free at madvise time.  munmap is "synchronous" at least (well,
> when file-backed).

The zapping means some TLB flush and page table clearly, so not free even at
madvise time.  And here we are talking about anon memory anyway, so not
file-backed.

	Jakub


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]