All of lore.kernel.org
 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 19:36:57 +0800	[thread overview]
Message-ID: <87k1414qli.fsf@yhuang-dev.intel.com> (raw)
In-Reply-To: <20200303081929.GY4380@dhcp22.suse.cz> (Michal Hocko's message of "Tue, 3 Mar 2020 09:19:29 +0100")

Michal Hocko <mhocko@kernel.org> writes:

> On Tue 03-03-20 09:30:28, Huang, Ying wrote:
> [...]
>> Yes.  mmap() can control whether to populate the underlying physical
>> pages.
>
> right because many usecases benefit from it. They simply know that the
> mapping will be used completely and it is worth saving overhead for #PF.
> See. there is a clear justification for that policy.
>
>> 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.
>
> Now let's have a look here. It is the userspace that decided to mark
> MADV_FREE pages. It is under its full control which pages are to be
> freed lazily. If the userspace wants to move those pages then it is
> likely aware they have been MADV_FREE, right? If the userspace wanted to
> save migration overhead then it could either chose to not migrate those
> pages or simply unmap them right away. So in the end we are talking
> about saving munmap/MAMDV_DONTNEED or potentially more move_pages calls
> to skip over MADV_FREE holes. Which is all nice but is there any
> userspace that really does care? Because this is a fundamental question
> here and it doesn't make much sense to discuss this left to right unless
> this is clear.

Although I don't agree with you, I don't want to continue.  Because I
feel that the discussion may be too general to go anywhere.  I admit
that I go to the general side firstly, sorry about that.

Best Regards,
Huang, Ying


      reply	other threads:[~2020-03-03 11:37 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
2020-03-03  8:19                 ` Michal Hocko
2020-03-03 11:36                   ` Huang, Ying [this message]

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=87k1414qli.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 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.