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. */ > > 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. > > 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 ? -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
