Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753126AbbKMGO6 (ORCPT ); Fri, 13 Nov 2015 01:14:58 -0500 Received: from LGEAMRELO13.lge.com ([156.147.23.53]:48336 "EHLO lgeamrelo13.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752871AbbKMGOh (ORCPT ); Fri, 13 Nov 2015 01:14:37 -0500 X-Original-SENDERIP: 156.147.1.121 X-Original-MAILFROM: minchan@kernel.org X-Original-SENDERIP: 165.244.98.203 X-Original-MAILFROM: minchan@kernel.org X-Original-SENDERIP: 10.177.223.161 X-Original-MAILFROM: minchan@kernel.org Date: Fri, 13 Nov 2015 15:15:11 +0900 From: Minchan Kim To: Daniel Micay CC: Andy Lutomirski , Andrew Morton , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , Michael Kerrisk , Linux API , Hugh Dickins , Johannes Weiner , Rik van Riel , Mel Gorman , KOSAKI Motohiro , Jason Evans , "Kirill A. Shutemov" , Shaohua Li , Michal Hocko , yalin wang Subject: Re: [PATCH v3 01/17] mm: support madvise(MADV_FREE) Message-ID: <20151113061511.GB5235@bbox> References: <1447302793-5376-1-git-send-email-minchan@kernel.org> <1447302793-5376-2-git-send-email-minchan@kernel.org> <564421DA.9060809@gmail.com> MIME-Version: 1.0 In-Reply-To: <564421DA.9060809@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-MIMETrack: Itemize by SMTP Server on LGEKRMHUB03/LGE/LG Group(Release 8.5.3FP3HF583 | August 9, 2013) at 2015/11/13 15:14:33, Serialize by Router on LGEKRMHUB03/LGE/LG Group(Release 8.5.3FP3HF583 | August 9, 2013) at 2015/11/13 15:14:33, Serialize complete at 2015/11/13 15:14:33 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1987 Lines: 47 On Thu, Nov 12, 2015 at 12:21:30AM -0500, Daniel Micay wrote: > > I also think that the kernel should commit to either zeroing the page > > or leaving it unchanged in response to MADV_FREE (even if the decision > > of which to do is made later on). I think that your patch series does > > this, but only after a few of the patches are applied (the swap entry > > freeing), and I think that it should be a real guaranteed part of the > > semantics and maybe have a test case. > > This would be a good thing to test because it would be required to add > MADV_FREE_UNDO down the road. It would mean the same semantics as the > MEM_RESET and MEM_RESET_UNDO features on Windows, and there's probably > value in that for the sake of migrating existing software too. So, do you mean that we could implement MADV_FREE_UNDO with "read" opearation("just access bit marking) easily in future? If so, it would be good reason to change MADV_FREE from dirty bit to access bit. Okay, I will look at that. > > For one example, it could be dropped into Firefox: > > https://dxr.mozilla.org/mozilla-central/source/memory/volatile/VolatileBufferWindows.cpp > > And in Chromium: > > https://code.google.com/p/chromium/codesearch#chromium/src/base/memory/discardable_shared_memory.cc > > Worth noting that both also support the API for pinning/unpinning that's > used by Android's ashmem too. Linux really needs a feature like this for > caches. Firefox simply doesn't drop the memory at all on Linux right now: > > https://dxr.mozilla.org/mozilla-central/source/memory/volatile/VolatileBufferFallback.cpp > > (Lock == pin, Unlock == unpin) > > For reference: > > https://msdn.microsoft.com/en-us/library/windows/desktop/aa366887(v=vs.85).aspx > -- 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/