All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: "Huang, Ying" <ying.huang@intel.com>, Michal Hocko <mhocko@kernel.org>
Cc: 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: Mon, 2 Mar 2020 15:23:16 +0100	[thread overview]
Message-ID: <8005e5a1-e2f2-1e57-ccb4-0cb9371b080d@redhat.com> (raw)
In-Reply-To: <87d09u7sm2.fsf@yhuang-dev.intel.com>

On 02.03.20 15:12, Huang, Ying wrote:
> Michal Hocko <mhocko@kernel.org> writes:
> 
>> On Fri 28-02-20 16:55:40, Huang, Ying wrote:
>>> David Hildenbrand <david@redhat.com> writes:
>> [...]
>>>> E.g., free page reporting in QEMU wants to use MADV_FREE. The guest will
>>>> report currently free pages to the hypervisor, which will MADV_FREE the
>>>> reported memory. As long as there is no memory pressure, there is no
>>>> need to actually free the pages. Once the guest reuses such a page, it
>>>> could happen that there is still the old page and pulling in in a fresh
>>>> (zeroed) page can be avoided.
>>>>
>>>> AFAIKs, after your change, we would get more pages discarded from our
>>>> guest, resulting in more fresh (zeroed) pages having to be pulled in
>>>> when a guest touches a reported free page again. But OTOH, page
>>>> migration is speed up (avoiding to migrate these pages).
>>>
>>> Let's look at this problem in another perspective.  To migrate the
>>> MADV_FREE pages of the QEMU process from the node A to the node B, we
>>> need to free the original pages in the node A, and (maybe) allocate the
>>> same number of pages in the node B.  So the question becomes
>>>
>>> - we may need to allocate some pages in the node B
>>> - these pages may be accessed by the application or not
>>> - we should allocate all these pages in advance or allocate them lazily
>>>   when they are accessed.
>>>
>>> We thought the common philosophy in Linux kernel is to allocate lazily.
>>
>> The common philosophy is to cache as much as possible.
> 
> Yes.  This is another common philosophy.  And MADV_FREE pages is
> different from caches such as the page caches because it has no valid
> contents.

Side note: It might contain valid content until discarded/zeroed out.
E.g., an application could use a marker bit (e.g., first bit) to detect
if the page still contains valid data or not. If the data is still
marked valid, the content could be reuse immediately. Not sure if there
is any such application, though :)

-- 
Thanks,

David / dhildenb


  reply	other threads:[~2020-03-02 14:23 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
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 [this message]
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=8005e5a1-e2f2-1e57-ccb4-0cb9371b080d@redhat.com \
    --to=david@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=alexander.duyck@gmail.com \
    --cc=dave.hansen@linux.intel.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=ying.huang@intel.com \
    --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.