From: "Huang\, Ying" <ying.huang@intel.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: Andrew Morton <akpm@linux-foundation.org>, <linux-mm@kvack.org>,
<linux-kernel@vger.kernel.org>,
David Hildenbrand <david@redhat.com>,
"Mel Gorman" <mgorman@suse.de>, Vlastimil Babka <vbabka@suse.cz>,
Zi Yan <ziy@nvidia.com>, Michal Hocko <mhocko@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Dave Hansen <dave.hansen@linux.intel.com>,
"Minchan Kim" <minchan@kernel.org>,
Johannes Weiner <hannes@cmpxchg.org>,
Hugh Dickins <hughd@google.com>
Subject: Re: [RFC 0/3] mm: Discard lazily freed pages when migrating
Date: Fri, 28 Feb 2020 15:25:32 +0800 [thread overview]
Message-ID: <87a7538977.fsf@yhuang-dev.intel.com> (raw)
In-Reply-To: <20200228034248.GE29971@bombadil.infradead.org> (Matthew Wilcox's message of "Thu, 27 Feb 2020 19:42:48 -0800")
Hi, Matthew,
Matthew Wilcox <willy@infradead.org> writes:
> On Fri, Feb 28, 2020 at 11:38:16AM +0800, Huang, Ying wrote:
>> MADV_FREE is a lazy free mechanism in Linux. According to the manpage
>> of mavise(2), the semantics of MADV_FREE is,
>>
>> The application no longer requires the pages in the range specified
>> by addr and len. The kernel can thus free these pages, but the
>> freeing could be delayed until memory pressure occurs. ...
>>
>> Originally, the pages freed lazily by MADV_FREE will only be freed
>> really by page reclaiming when there is memory pressure or when
>> unmapping the address range. In addition to that, there's another
>> opportunity to free these pages really, when we try to migrate them.
>>
>> The main value to do that is to avoid to create the new memory
>> pressure immediately if possible. Instead, even if the pages are
>> required again, they will be allocated gradually on demand. That is,
>> the memory will be allocated lazily when necessary. This follows the
>> common philosophy in the Linux kernel, allocate resources lazily on
>> demand.
>
> Do you have an example program which does this (and so benefits)?
Sorry, what do you mean exactly for "this" here? Call
madvise(,,MADV_FREE)? Or migrate pages?
> If so, can you quantify the benefit at all?
The question is what is the right workload? For example, I can build a
scenario as below to show benefit.
- run program A in node 0 with many lazily freed pages
- run program B in node 1, so that the free memory on node 1 is low
- migrate the program A from node 0 to node 1, so that the program B is
influenced by the memory pressure created by migrating lazily freed
pages.
Best Regards,
Huang, Ying
next prev parent reply other threads:[~2020-02-28 7:25 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-28 3:38 [RFC 0/3] mm: Discard lazily freed pages when migrating Huang, Ying
2020-02-28 3:38 ` [RFC 1/3] mm, migrate: Check return value of try_to_unmap() Huang, Ying
2020-02-28 3:38 ` [RFC 2/3] mm: Add a new page flag PageLayzyFree() for MADV_FREE Huang, Ying
2020-02-28 6:13 ` David Hildenbrand
2020-02-28 6:47 ` Huang, Ying
2020-02-28 6:47 ` Huang, Ying
2020-03-15 8:18 ` Wei Yang
2020-03-15 8:54 ` Mika Penttilä
2020-03-15 12:22 ` Wei Yang
2020-03-16 1:21 ` Huang, Ying
2020-03-16 1:21 ` Huang, Ying
2020-03-16 22:38 ` Wei Yang
2020-02-28 3:38 ` [RFC 3/3] mm: Discard lazily freed pages when migrating Huang, Ying
2020-02-28 3:42 ` [RFC 0/3] " Matthew Wilcox
2020-02-28 7:25 ` Huang, Ying [this message]
2020-02-28 7:25 ` Huang, Ying
2020-02-28 8:22 ` David Hildenbrand
2020-02-28 8:55 ` Huang, Ying
2020-02-28 8:55 ` Huang, Ying
2020-02-28 9:49 ` Mel Gorman
2020-03-02 11:23 ` Huang, Ying
2020-03-02 11:23 ` Huang, Ying
2020-03-02 15:16 ` Mel Gorman
2020-03-03 1:51 ` Huang, Ying
2020-03-03 1:51 ` Huang, Ying
2020-03-03 8:09 ` Michal Hocko
2020-03-03 8:47 ` Huang, Ying
2020-03-03 8:47 ` Huang, Ying
2020-03-03 8:58 ` Michal Hocko
2020-03-03 11:49 ` Huang, Ying
2020-03-03 11:49 ` Huang, Ying
2020-03-04 9:58 ` Michal Hocko
2020-03-04 10:56 ` Mel Gorman
2020-03-05 1:42 ` Huang, Ying
2020-03-05 1:42 ` Huang, Ying
2020-03-04 11:15 ` Huang, Ying
2020-03-04 11:15 ` Huang, Ying
2020-03-04 11:26 ` Michal Hocko
2020-03-05 1:45 ` Huang, Ying
2020-03-05 1:45 ` Huang, Ying
2020-03-05 10:48 ` Mel Gorman
2020-03-06 4:05 ` Huang, Ying
2020-03-06 4:05 ` Huang, Ying
2020-03-09 5:26 ` Huang, Ying
2020-03-09 5:26 ` Huang, Ying
2020-03-03 13:02 ` Mel Gorman
2020-03-04 0:33 ` Huang, Ying
2020-03-04 0:33 ` Huang, Ying
2020-02-28 9:50 ` Michal Hocko
2020-02-28 10:15 ` Michal Hocko
2020-02-28 13:45 ` Johannes Weiner
2020-03-02 14:12 ` Huang, Ying
2020-03-02 14:12 ` Huang, Ying
2020-03-02 14:23 ` David Hildenbrand
2020-03-03 0:25 ` Huang, Ying
2020-03-03 0:25 ` Huang, Ying
2020-03-02 14:25 ` Michal Hocko
2020-03-03 1:30 ` Huang, Ying
2020-03-03 1:30 ` Huang, Ying
2020-03-03 8:19 ` Michal Hocko
2020-03-03 11:36 ` Huang, Ying
2020-03-03 11:36 ` Huang, Ying
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=87a7538977.fsf@yhuang-dev.intel.com \
--to=ying.huang@intel.com \
--cc=akpm@linux-foundation.org \
--cc=dave.hansen@linux.intel.com \
--cc=david@redhat.com \
--cc=hannes@cmpxchg.org \
--cc=hughd@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=mhocko@kernel.org \
--cc=minchan@kernel.org \
--cc=peterz@infradead.org \
--cc=vbabka@suse.cz \
--cc=willy@infradead.org \
--cc=ziy@nvidia.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.