[lkml]   [2017]   [Jul]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC PATCH 0/1] mm/mremap: add MREMAP_MIRROR flag
On 07/07/2017 01:19 AM, Anshuman Khandual wrote:
> On 07/06/2017 09:47 PM, Mike Kravetz wrote:
>> The mremap system call has the ability to 'mirror' parts of an existing
>> mapping. To do so, it creates a new mapping that maps the same pages as
>> the original mapping, just at a different virtual address. This
>> functionality has existed since at least the 2.6 kernel [1]. A comment
>> was added to the code to help preserve this feature.
> Is this the comment ? If yes, then its not very clear.
> /*
> * We allow a zero old-len as a special case
> * for DOS-emu "duplicate shm area" thing. But
> * a zero new-len is nonsensical.
> */

Yes, I believe that is the comment.

>> The Oracle JVM team has discovered this feature and used it while
>> prototyping a new garbage collection model. This new model shows promise,
>> and they are considering its use in a future release. However, since
>> the only mention of this functionality is a single comment in the kernel,
>> they are concerned about its future.
>> I propose the addition of a new MREMAP_MIRROR flag to explicitly request
>> this functionality. The flag simply provides the same functionality as
>> the existing undocumented 'old_size == 0' interface. As an alternative,
>> we could simply document the 'old_size == 0' interface in the man page.
>> In either case, man page modifications would be needed.
> Right. Adding MREMAP_MIRROR sounds cleaner from application programming
> point of view. But it extends the interface.

Yes. That is the reason for the RFC. We currently have functionality
that is not clearly part of a programming interface. Application programmers
do not like to depend on something that is not part of an interface.

>> Future Direction
>> After more formally adding this to the API (either new flag or documenting
>> existing interface), the mremap code could be enhanced to optimize this
>> case. Currently, 'mirroring' only sets up the new mapping. It does not
>> create page table entries for new mapping. This could be added as an
>> enhancement.
> Then how it achieves mirroring, both the pointers should see the same
> data, that can happen with page table entries pointing to same pages,
> right ?


In the code today, page tables for the new (mirrored) mapping are created
as needed via faults. The enhancement would be to create page table entries
for the new mapping.

Mike Kravetz

 \ /
  Last update: 2017-07-07 19:05    [W:0.117 / U:4.028 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site