From: Daniel Micay <danielmicay@gmail.com>
To: Shaohua Li <shli@fb.com>, linux-mm@kvack.org
Cc: Kernel-team@fb.com, Rik van Riel <riel@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
Hugh Dickins <hughd@google.com>,
Andy Lutomirski <luto@amacapital.net>
Subject: Re: [RFC] mremap: add MREMAP_NOHOLE flag
Date: Tue, 03 Feb 2015 18:02:28 -0500 [thread overview]
Message-ID: <54D15384.7040605@gmail.com> (raw)
In-Reply-To: <7064772f72049de8a79383105f49b5db84a946e5.1422990665.git.shli@fb.com>
[-- Attachment #1: Type: text/plain, Size: 1240 bytes --]
I think this would be very useful in some compacting garbage collectors
even in non-reallocation case too. A heap of large objects could be
compacted by transitioning between two huge regions of address space by
moving the pages with mremap. It's simple enough to cope with an
unaligned head/tail using memcpy if allocations aren't page aligned.
Of course, garbage collectors would also benefit from the ability to
make use of mremap for reallocations just as allocators like jemalloc
and tcmalloc would.
If you're unable to build enough interest in it based on the use case
for it inside allocators like jemalloc/tcmalloc, then I would suggest
poking the developers of the GCs in v8, etc. about it to see if they
have any use case for this.
It may be worth considering a new restricted system call instead of
extending mremap. Since the primary use case is about moving pages from
one region to another existing region, I see the potential for it to be
done without an exclusive mmap_sem lock just like MADV_{DONTNEED,FREE}
and page faulting. This would give up the ability to grow in-place but
that only happens if virtual memory is being fragmented anyway. The
destination and source would also need to match.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
next prev parent reply other threads:[~2015-02-03 23:02 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-03 19:19 [RFC] mremap: add MREMAP_NOHOLE flag Shaohua Li
2015-02-03 23:02 ` Daniel Micay [this message]
2015-02-04 10:22 ` Michael Kerrisk
2015-02-23 22:10 ` Shaohua Li
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54D15384.7040605@gmail.com \
--to=danielmicay@gmail.com \
--cc=Kernel-team@fb.com \
--cc=akpm@linux-foundation.org \
--cc=hughd@google.com \
--cc=linux-mm@kvack.org \
--cc=luto@amacapital.net \
--cc=riel@redhat.com \
--cc=shli@fb.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).