From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1031779AbbKEA4T (ORCPT ); Wed, 4 Nov 2015 19:56:19 -0500 Received: from LGEAMRELO11.lge.com ([156.147.23.51]:54921 "EHLO lgeamrelo11.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1031658AbbKEAz7 (ORCPT ); Wed, 4 Nov 2015 19:55:59 -0500 X-Original-SENDERIP: 156.147.1.126 X-Original-MAILFROM: minchan@kernel.org X-Original-SENDERIP: 10.177.223.161 X-Original-MAILFROM: minchan@kernel.org Date: Thu, 5 Nov 2015 09:56:07 +0900 From: Minchan Kim To: Andy Lutomirski 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 Subject: Re: [PATCH v2 01/13] mm: support madvise(MADV_FREE) Message-ID: <20151105005607.GE7357@bbox> References: <1446600367-7976-1-git-send-email-minchan@kernel.org> <1446600367-7976-2-git-send-email-minchan@kernel.org> <20151105001348.GC7357@bbox> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Nov 04, 2015 at 04:42:37PM -0800, Andy Lutomirski wrote: > 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? I meant if we use access bit as indicator for lazy-freeing page, we could discard valid page which is never hinted by MADV_FREE but just doesn't mark access bit in page table by aging algorithm. > > >> > >> > + 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? Kernel shouldn't make the page clean without writeback(ie, swapout) if the page has valid data. > > > --Andy > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majordomo@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 From: Minchan Kim Subject: Re: [PATCH v2 01/13] mm: support madvise(MADV_FREE) Date: Thu, 5 Nov 2015 09:56:07 +0900 Message-ID: <20151105005607.GE7357@bbox> References: <1446600367-7976-1-git-send-email-minchan@kernel.org> <1446600367-7976-2-git-send-email-minchan@kernel.org> <20151105001348.GC7357@bbox> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: Sender: owner-linux-mm@kvack.org To: Andy Lutomirski 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 List-Id: linux-api@vger.kernel.org On Wed, Nov 04, 2015 at 04:42:37PM -0800, Andy Lutomirski wrote: > 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? I meant if we use access bit as indicator for lazy-freeing page, we could discard valid page which is never hinted by MADV_FREE but just doesn't mark access bit in page table by aging algorithm. > > >> > >> > + 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? Kernel shouldn't make the page clean without writeback(ie, swapout) if the page has valid data. > > > --Andy > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majordomo@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: email@kvack.org -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org