Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932907AbdGJRXC (ORCPT ); Mon, 10 Jul 2017 13:23:02 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:43756 "EHLO aserp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932275AbdGJRW7 (ORCPT ); Mon, 10 Jul 2017 13:22:59 -0400 Subject: Re: [RFC PATCH 1/1] mm/mremap: add MREMAP_MIRROR flag for existing mirroring functionality To: Vlastimil Babka , Anshuman Khandual , "Kirill A. Shutemov" References: <1499357846-7481-1-git-send-email-mike.kravetz@oracle.com> <1499357846-7481-2-git-send-email-mike.kravetz@oracle.com> <20170707102324.kfihkf72sjcrtn5b@node.shutemov.name> <20170707174534.wdfbciyfpovi52dy@node.shutemov.name> <79eca23d-9f1a-9713-3f6b-8f7598d53190@oracle.com> <662d372a-5737-5f0b-8ac1-c997f3a935eb@linux.vnet.ibm.com> <223c0ede-1203-4ea6-0157-a4500fea8050@suse.cz> Cc: linux-mm@kvack.org, linux-api@vger.kernel.org, linux-kernel@vger.kernel.org, Andrew Morton , Andrea Arcangeli , Michal Hocko , Aaron Lu , "Kirill A . Shutemov" From: Mike Kravetz Message-ID: Date: Mon, 10 Jul 2017 10:22:09 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <223c0ede-1203-4ea6-0157-a4500fea8050@suse.cz> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Source-IP: aserv0021.oracle.com [141.146.126.233] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2269 Lines: 50 On 07/10/2017 09:22 AM, Vlastimil Babka wrote: > On 07/09/2017 09:32 AM, Anshuman Khandual wrote: >> On 07/07/2017 11:39 PM, Mike Kravetz wrote: >>> On 07/07/2017 10:45 AM, Kirill A. Shutemov wrote: >>>> On Fri, Jul 07, 2017 at 10:29:52AM -0700, Mike Kravetz wrote: >>>>> On 07/07/2017 03:23 AM, Kirill A. Shutemov wrote: >>>>>> What is going to happen to mirrored after CoW for instance? >>>>>> >>>>>> In my opinion, it shouldn't be allowed for anon/private mappings at least. >>>>>> And with this limitation, I don't see much sense in the new interface -- >>>>>> just create mirror by mmap()ing the file again. >>>>> >>>>> The code today works for anon shared mappings. See simple program below. >>>>> >>>>> You are correct in that it makes little or no sense for private mappings. >>>>> When looking closer at existing code, mremap() creates a new private >>>>> mapping in this case. This is most likely a bug. >>>> >>>> IIRC, existing code doesn't create mirrors of private pages as it requires >>>> old_len to be zero. There's no way to get private pages mapped twice this >>>> way. >>> >>> Correct. >>> As mentioned above, mremap does 'something' for private anon pages when >>> old_len == 0. However, this may be considered a bug. In this case, mremap >>> creates a new private anon mapping of length new_size. Since old_len == 0, >>> it does not unmap any of the old mapping. So, in this case mremap basically >>> creates a new private mapping (unrealted to the original) and does not >>> modify the old mapping. >>> >> >> Yeah, in my experiment, after the mremap() exists we have two different VMAs >> which can contain two different set of data. No page sharing is happening. > > So how does this actually work for the JVM garbage collector use case? > Aren't the garbage collected objects private anon? Good point. The sample program the JVM team gave me uses a shared anon mapping. As you mention one would expect these mappings to be private. I have asked them for more details on their use case. > Anyway this should be documented. Yes, their prototype work seems to take advantage of this existing undocumented behavior. It seems we have been carrying this functionality for at least 13 years. It may be time to document. -- Mike Kravetz