On Mon, Oct 26, 2015 at 06:28:13PM -0700, Hugh Dickins wrote: > On Mon, 19 Oct 2015, Minchan Kim wrote: > > > Basically, MADV_FREE relies on dirty bit in page table entry > > to decide whether VM allows to discard the page or not. > > IOW, if page table entry includes marked dirty bit, VM shouldn't > > discard the page. > > > > However, as a example, if swap-in by read fault happens, > > page table entry doesn't have dirty bit so MADV_FREE could discard > > the page wrongly. > > > > For avoiding the problem, MADV_FREE did more checks with PageDirty > > and PageSwapCache. It worked out because swapped-in page lives on > > swap cache and since it is evicted from the swap cache, the page has > > PG_dirty flag. So both page flags check effectively prevent > > wrong discarding by MADV_FREE. > > > > However, a problem in above logic is that swapped-in page has > > PG_dirty still after they are removed from swap cache so VM cannot > > consider the page as freeable any more even if madvise_free is > > called in future. > > > > Look at below example for detail. > > > > ptr = malloc(); > > memset(ptr); > > .. > > .. > > .. heavy memory pressure so all of pages are swapped out > > .. > > .. > > var = *ptr; -> a page swapped-in and could be removed from > > swapcache. Then, page table doesn't mark > > dirty bit and page descriptor includes PG_dirty > > .. > > .. > > madvise_free(ptr); -> It doesn't clear PG_dirty of the page. > > .. > > .. > > .. > > .. heavy memory pressure again. > > .. In this time, VM cannot discard the page because the page > > .. has *PG_dirty* > > > > To solve the problem, this patch clears PG_dirty if only the page > > is owned exclusively by current process when madvise is called > > because PG_dirty represents ptes's dirtiness in several processes > > so we could clear it only if we own it exclusively. > > > > Cc: Hugh Dickins <hu...@google.com> > > Signed-off-by: Minchan Kim <minc...@kernel.org> > > Acked-by: Hugh Dickins <hu...@google.com> > > (and patches 1/5 and 2/5 too if you like) >
Thanks for the review, Hugh! I will rebase all series from the beginning as you suggested and will add your Acked-by because I feel you just reviewed all of MADV_FREE code line and you have no found any problem. If something happens(ie, I abuse your Acked-by) wrong, please shout me. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
