From: Arun Sharma <asharma@fb.com>
To: Minchan Kim <minchan@kernel.org>
Cc: KOSAKI Motohiro <kosaki.motohiro@gmail.com>,
Paul Turner <pjt@google.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
John Stultz <john.stultz@linaro.org>,
Christoph Lameter <cl@linux.com>,
Android Kernel Team <kernel-team@android.com>,
Robert Love <rlove@google.com>, Mel Gorman <mel@csn.ul.ie>,
Hugh Dickins <hughd@google.com>,
Dave Hansen <dave@linux.vnet.ibm.com>,
Rik van Riel <riel@redhat.com>,
Dave Chinner <david@fromorbit.com>, Neil Brown <neilb@suse.de>,
Mike Hommey <mh@glandium.org>, Taras Glek <tglek@mozilla.com>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
sanjay@google.com, David Rientjes <rientjes@google.com>
Subject: Re: [RFC v2] Support volatile range for anon vma
Date: Mon, 5 Nov 2012 18:03:48 -0800 [thread overview]
Message-ID: <50987004.1000003@fb.com> (raw)
In-Reply-To: <20121106014932.GA4623@barrios>
On 11/5/12 5:49 PM, Minchan Kim wrote:
>> Also, memory allocators have a second motivation in using madvise: to
>> create virtually contiguous regions of memory from a fragmented address
>> space, without increasing the RSS.
>
> I don't get it. How do we create contiguos region by madvise?
> Just out of curiosity.
> Could you elaborate that use case? :)
By using a new anonymous map and faulting pages in.
The fragmented virtual memory is released via MADV_DONTNEED and if the
malloc/free activity on the system is dominated by one process, chances
are that the newly faulted in page is the one released by the same
process :)
The net effect is that physical pages within a single address space are
rearranged so larger allocations can be satisfied.
-Arun
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Arun Sharma <asharma@fb.com>
To: Minchan Kim <minchan@kernel.org>
Cc: KOSAKI Motohiro <kosaki.motohiro@gmail.com>,
Paul Turner <pjt@google.com>,
Andrew Morton <akpm@linux-foundation.org>,
<linux-kernel@vger.kernel.org>, <linux-mm@kvack.org>,
John Stultz <john.stultz@linaro.org>,
Christoph Lameter <cl@linux.com>,
Android Kernel Team <kernel-team@android.com>,
Robert Love <rlove@google.com>, Mel Gorman <mel@csn.ul.ie>,
Hugh Dickins <hughd@google.com>,
Dave Hansen <dave@linux.vnet.ibm.com>,
Rik van Riel <riel@redhat.com>,
Dave Chinner <david@fromorbit.com>, Neil Brown <neilb@suse.de>,
Mike Hommey <mh@glandium.org>, Taras Glek <tglek@mozilla.com>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
<sanjay@google.com>, David Rientjes <rientjes@google.com>
Subject: Re: [RFC v2] Support volatile range for anon vma
Date: Mon, 5 Nov 2012 18:03:48 -0800 [thread overview]
Message-ID: <50987004.1000003@fb.com> (raw)
In-Reply-To: <20121106014932.GA4623@barrios>
On 11/5/12 5:49 PM, Minchan Kim wrote:
>> Also, memory allocators have a second motivation in using madvise: to
>> create virtually contiguous regions of memory from a fragmented address
>> space, without increasing the RSS.
>
> I don't get it. How do we create contiguos region by madvise?
> Just out of curiosity.
> Could you elaborate that use case? :)
By using a new anonymous map and faulting pages in.
The fragmented virtual memory is released via MADV_DONTNEED and if the
malloc/free activity on the system is dominated by one process, chances
are that the newly faulted in page is the one released by the same
process :)
The net effect is that physical pages within a single address space are
rearranged so larger allocations can be satisfied.
-Arun
next prev parent reply other threads:[~2012-11-06 2:07 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-30 1:29 [RFC v2] Support volatile range for anon vma Minchan Kim
2012-10-30 1:29 ` Minchan Kim
2012-10-31 21:35 ` Andrew Morton
2012-10-31 21:35 ` Andrew Morton
2012-10-31 21:59 ` Paul Turner
2012-10-31 21:59 ` Paul Turner
2012-10-31 22:56 ` KOSAKI Motohiro
2012-10-31 22:56 ` KOSAKI Motohiro
2012-11-01 1:15 ` Paul Turner
2012-11-01 1:15 ` Paul Turner
2012-11-01 1:46 ` Minchan Kim
2012-11-01 1:46 ` Minchan Kim
2012-11-01 1:25 ` Minchan Kim
2012-11-01 1:25 ` Minchan Kim
2012-11-01 2:01 ` KOSAKI Motohiro
2012-11-01 2:01 ` KOSAKI Motohiro
2012-11-05 23:54 ` Arun Sharma
2012-11-05 23:54 ` Arun Sharma
2012-11-06 1:49 ` Minchan Kim
2012-11-06 1:49 ` Minchan Kim
2012-11-06 2:03 ` Arun Sharma [this message]
2012-11-06 2:03 ` Arun Sharma
2012-11-01 0:50 ` Minchan Kim
2012-11-01 0:50 ` Minchan Kim
2012-11-01 1:22 ` Paul Turner
2012-11-01 1:22 ` Paul Turner
2012-11-01 1:33 ` Minchan Kim
2012-11-01 1:33 ` Minchan Kim
2012-11-01 0:21 ` Minchan Kim
2012-11-01 0:21 ` Minchan Kim
2012-11-02 1:43 ` Bob Liu
2012-11-02 1:43 ` Bob Liu
2012-11-02 2:37 ` Minchan Kim
2012-11-02 2:37 ` Minchan Kim
2012-11-22 0:36 ` John Stultz
2012-11-22 0:36 ` John Stultz
2012-11-29 4:18 ` John Stultz
2012-11-29 4:18 ` John Stultz
2012-12-04 0:00 ` Minchan Kim
2012-12-04 0:00 ` Minchan Kim
2012-12-04 0:57 ` John Stultz
2012-12-04 0:57 ` John Stultz
2012-12-04 7:22 ` Minchan Kim
2012-12-04 7:22 ` Minchan Kim
2012-12-04 19:13 ` John Stultz
2012-12-04 19:13 ` John Stultz
2012-12-05 4:18 ` Minchan Kim
2012-12-05 4:18 ` Minchan Kim
2012-12-08 0:49 ` John Stultz
2012-12-08 0:49 ` John Stultz
2012-12-11 4:40 ` Minchan Kim
2012-12-11 4:40 ` Minchan Kim
2012-12-05 7:01 ` Minchan Kim
2012-12-05 7:01 ` Minchan Kim
2012-12-08 0:20 ` John Stultz
2012-12-08 0:20 ` John Stultz
2012-12-11 4:34 ` Minchan Kim
2012-12-11 4:34 ` Minchan Kim
2012-12-03 23:50 ` Minchan Kim
2012-12-03 23:50 ` Minchan Kim
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=50987004.1000003@fb.com \
--to=asharma@fb.com \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=dave@linux.vnet.ibm.com \
--cc=david@fromorbit.com \
--cc=hughd@google.com \
--cc=john.stultz@linaro.org \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=kernel-team@android.com \
--cc=kosaki.motohiro@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mel@csn.ul.ie \
--cc=mh@glandium.org \
--cc=minchan@kernel.org \
--cc=neilb@suse.de \
--cc=pjt@google.com \
--cc=riel@redhat.com \
--cc=rientjes@google.com \
--cc=rlove@google.com \
--cc=sanjay@google.com \
--cc=tglek@mozilla.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.