linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Huang\, Ying" <ying.huang@intel.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: David Hildenbrand <david@redhat.com>,
	 Matthew Wilcox <willy@infradead.org>,
	 Andrew Morton <akpm@linux-foundation.org>,  <linux-mm@kvack.org>,
	 <linux-kernel@vger.kernel.org>,  Mel Gorman <mgorman@suse.de>,
	 Vlastimil Babka <vbabka@suse.cz>,  Zi Yan <ziy@nvidia.com>,
	 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>,
	 "Alexander Duyck" <alexander.duyck@gmail.com>
Subject: Re: [RFC 0/3] mm: Discard lazily freed pages when migrating
Date: Tue, 03 Mar 2020 09:30:28 +0800	[thread overview]
Message-ID: <874kv66x8r.fsf@yhuang-dev.intel.com> (raw)
In-Reply-To: <20200302142549.GO4380@dhcp22.suse.cz> (Michal Hocko's message of "Mon, 2 Mar 2020 15:25:49 +0100")

Michal Hocko <mhocko@kernel.org> writes:

> On Mon 02-03-20 22:12:53, Huang, Ying wrote:
>> Michal Hocko <mhocko@kernel.org> writes:
> [...]
>> > And MADV_FREE pages are a kind of cache as well. If the target node is
>> > short on memory then those will be reclaimed as a cache so a
>> > pro-active freeing sounds counter productive as you do not have any
>> > idea whether that cache is going to be used in future. In other words
>> > you are not going to free a clean page cache if you want to use that
>> > memory as a migration target right? So you should make a clear case
>> > about why MADV_FREE cache is less important than the clean page cache
>> > and ideally have a good justification backed by real workloads.
>> 
>> Clean page cache still have valid contents, while clean MADV_FREE pages
>> has no valid contents.  So penalty of discarding the clean page cache is
>> reading from disk, while the penalty of discarding clean MADV_FREE pages
>> is just page allocation and zeroing.
>
> And "just page allocation and zeroing" overhead is the primary
> motivation to keep the page in memory. It is a decision of the workload
> to use MADV_FREE because chances are that this will speed things up. All
> that with a contract that the memory goes away under memory pressure so
> with a good workload/memory sizing you do not really lose that
> optimization. Now you want to make decision on behalf of the consumer of
> the MADV_FREE memory.

I understand that MADV_FREE helps in some situations.  And if the
application want to keep the "contract" after migration, they should
have a way to do that.

>> I understand that MADV_FREE is another kind of cache and has its value.
>> But in the original implementation, during migration, we have already
>> freed the original "cache", then reallocate the cache elsewhere and
>> copy.  This appears more like all pages are populated in mmap() always.
>> I know there's value to populate all pages in mmap(), but does that need
>> to be done always by default?
>
> It is not. You have to explicitly request MAP_POPULATE to initialize
> mmap.

Yes.  mmap() can control whether to populate the underlying physical
pages.  But for migrating MADV_FREE pages, there's no control, all pages
will be populated again always by default.  Maybe we should avoid to do
that in some situations too.

Best Regards,
Huang, Ying


  reply	other threads:[~2020-03-03  1:30 UTC|newest]

Thread overview: 44+ 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-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 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
2020-02-28  8:22     ` David Hildenbrand
2020-02-28  8:55       ` Huang, Ying
2020-02-28  9:49         ` Mel Gorman
2020-03-02 11:23           ` Huang, Ying
2020-03-02 15:16             ` Mel Gorman
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:58                     ` Michal Hocko
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-04 11:15                           ` Huang, Ying
2020-03-04 11:26                             ` Michal Hocko
2020-03-05  1:45                               ` Huang, Ying
2020-03-05 10:48                             ` Mel Gorman
2020-03-06  4:05                               ` Huang, Ying
2020-03-09  5:26                               ` Huang, Ying
2020-03-03 13:02                 ` Mel Gorman
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:23             ` David Hildenbrand
2020-03-03  0:25               ` Huang, Ying
2020-03-02 14:25             ` Michal Hocko
2020-03-03  1:30               ` Huang, Ying [this message]
2020-03-03  8:19                 ` Michal Hocko
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=874kv66x8r.fsf@yhuang-dev.intel.com \
    --to=ying.huang@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=alexander.duyck@gmail.com \
    --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 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).