Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932891AbbKEAm7 (ORCPT ); Wed, 4 Nov 2015 19:42:59 -0500 Received: from mail-ob0-f181.google.com ([209.85.214.181]:36821 "EHLO mail-ob0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932414AbbKEAm5 (ORCPT ); Wed, 4 Nov 2015 19:42:57 -0500 MIME-Version: 1.0 In-Reply-To: <20151105001348.GC7357@bbox> References: <1446600367-7976-1-git-send-email-minchan@kernel.org> <1446600367-7976-2-git-send-email-minchan@kernel.org> <20151105001348.GC7357@bbox> From: Andy Lutomirski Date: Wed, 4 Nov 2015 16:42:37 -0800 Message-ID: Subject: Re: [PATCH v2 01/13] mm: support madvise(MADV_FREE) To: Minchan Kim Cc: Hugh Dickins , Andrew Morton , Michael Kerrisk , Michal Hocko , "linux-mm@kvack.org" , KOSAKI Motohiro , "Kirill A. Shutemov" , Rik van Riel , Johannes Weiner , Linux API , Jason Evans , Shaohua Li , "linux-kernel@vger.kernel.org" , yalin wang , Daniel Micay , Mel Gorman Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3545 Lines: 87 On Wed, Nov 4, 2015 at 4:13 PM, Minchan Kim wrote: > On Tue, Nov 03, 2015 at 07:41:35PM -0800, Andy Lutomirski wrote: >> On Nov 3, 2015 5:30 PM, "Minchan Kim" wrote: >> > >> > Linux doesn't have an ability to free pages lazy while other OS already >> > have been supported that named by madvise(MADV_FREE). >> > >> > The gain is clear that kernel can discard freed pages rather than swapping >> > out or OOM if memory pressure happens. >> > >> > Without memory pressure, freed pages would be reused by userspace without >> > another additional overhead(ex, page fault + allocation + zeroing). >> > >> >> [...] >> >> > >> > How it works: >> > >> > When madvise syscall is called, VM clears dirty bit of ptes of the range. >> > If memory pressure happens, VM checks dirty bit of page table and if it >> > found still "clean", it means it's a "lazyfree pages" so VM could discard >> > the page instead of swapping out. Once there was store operation for the >> > page before VM peek a page to reclaim, dirty bit is set so VM can swap out >> > the page instead of discarding. >> >> What happens if you MADV_FREE something that's MAP_SHARED or isn't >> ordinary anonymous memory? There's a long history of MADV_DONTNEED on >> such mappings causing exploitable problems, and I think it would be >> nice if MADV_FREE were obviously safe. > > It filter out VM_LOCKED|VM_HUGETLB|VM_PFNMAP and file-backed vma and MAP_SHARED > with vma_is_anonymous. > >> >> Does this set the write protect bit? > > No. > >> >> What happens on architectures without hardware dirty tracking? For >> that matter, even on architecture with hardware dirty tracking, what >> happens in multithreaded processes that have the dirty TLB state >> cached in a different CPU's TLB? >> >> Using the dirty bit for these semantics scares me. This API creates a >> page that can have visible nonzero contents and then can >> asynchronously and magically zero itself thereafter. That makes me >> nervous. Could we use the accessed bit instead? Then the observable > > Access bit is used by aging algorithm for reclaim. In addition, > we have supported clear_refs feacture. > IOW, it could be reset anytime so it's hard to use marker for > lazy freeing at the moment. > That's unfortunate. I think that the ABI would be much nicer if it used the accessed bit. In any case, shouldn't the aging algorithm be irrelevant here? A MADV_FREE page that isn't accessed can be discarded, whereas we could hopefully just say that a MADV_FREE page that is accessed gets moved to whatever list holds recently accessed pages and also stops being a candidate for discarding due to MADV_FREE? >> >> > + if (!PageDirty(page) && (flags & TTU_FREE)) { >> > + /* It's a freeable page by MADV_FREE */ >> > + dec_mm_counter(mm, MM_ANONPAGES); >> > + goto discard; >> > + } >> >> Does something clear TTU_FREE the next time the page gets marked clean? > > Sorry, I don't understand. Could you elaborate it more? I don't fully understand how TTU_FREE ends up being set here, but, if the page is dirtied by user code and then cleaned later by the kernel, what prevents TTU_FREE from being incorrectly set here? --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/