From: Dave Hansen <dave.hansen@intel.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: Minchan Kim <minchan@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
linux-mm <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>,
linux-api@vger.kernel.org, Johannes Weiner <hannes@cmpxchg.org>,
Tim Murray <timmurray@google.com>,
Joel Fernandes <joel@joelfernandes.org>,
Suren Baghdasaryan <surenb@google.com>,
Daniel Colascione <dancol@google.com>,
Shakeel Butt <shakeelb@google.com>,
Sonny Rao <sonnyrao@google.com>,
oleksandr@redhat.com, hdanton@sina.com, lizeb@google.com,
"Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>
Subject: Re: [PATCH v3 1/5] mm: introduce MADV_COLD
Date: Thu, 27 Jun 2019 07:36:50 -0700 [thread overview]
Message-ID: <d9341eb3-08eb-3c2b-9786-00b8a4f59953@intel.com> (raw)
In-Reply-To: <20190627140203.GB5303@dhcp22.suse.cz>
On 6/27/19 7:02 AM, Michal Hocko wrote:
>> Is the LRU behavior part of the interface or the implementation?
>>
>> I ask because we've got something in between tossing something down the
>> LRU and swapping it: page migration. Specifically, on a system with
>> slower memory media (like persistent memory) we just migrate a page
>> instead of discarding it at reclaim:
> But we already do have interfaces for migrating the memory
> (move_pages(2)). Why should this interface duplicate that interface?
> I believe the only purpose of these two new madvise modes is to provide
> a non-destructive MADV_{DONTNEED,FREE} alteternatives. In other words,
> pageout vs. age interface.
The existing interface's problem for this case is that it has to know
exact locations where the memory is and where it should go. For
instance, if you have two sockets, you very likely want to demote DRAM
to the persistent memory DIMM sitting next to it and not go
cross-socket. To do _that_, you need to know where the existing
allocation lies so you can find the appropriate destination node.
That's not a problem for existing NUMA-enlightened apps, but it is for
everything else.
For MADV_COLD, if we defined it like this, I think we could use it for
both purposes (demotion and LRU movement):
Pages in the specified regions will be treated as less-recently-
accessed compared to pages in the system with similar access
frequencies. In contrast to MADV_DONTNEED, the contents of the
region are preserved.
It would be nice not to talk about reclaim at all since we're not
promising reclaim per se.
next prev parent reply other threads:[~2019-06-27 14:36 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-27 11:54 [PATCH v3 0/5] Introduce MADV_COLD and MADV_PAGEOUT Minchan Kim
2019-06-27 11:54 ` [PATCH v3 1/5] mm: introduce MADV_COLD Minchan Kim
2019-06-27 13:13 ` Dave Hansen
2019-06-27 14:02 ` Michal Hocko
2019-06-27 14:36 ` Dave Hansen [this message]
2019-06-27 14:53 ` Michal Hocko
2019-06-27 23:56 ` Minchan Kim
2019-07-01 7:35 ` Minchan Kim
2019-07-01 7:35 ` Minchan Kim
2019-07-09 9:19 ` Michal Hocko
2019-06-27 23:46 ` Minchan Kim
2019-06-27 11:54 ` [PATCH v3 2/5] mm: change PAGEREF_RECLAIM_CLEAN with PAGE_REFRECLAIM Minchan Kim
2019-06-27 11:54 ` [PATCH v3 3/5] mm: account nr_isolated_xxx in [isolate|putback]_lru_page Minchan Kim
2019-07-09 9:38 ` Michal Hocko
2019-06-27 11:54 ` [PATCH v3 4/5] mm: introduce MADV_PAGEOUT Minchan Kim
2019-07-09 9:55 ` Michal Hocko
2019-07-10 10:48 ` Minchan Kim
2019-07-10 11:16 ` Michal Hocko
2019-07-10 11:53 ` Minchan Kim
2019-07-10 19:47 ` Michal Hocko
2019-07-11 0:25 ` Minchan Kim
2019-06-27 11:54 ` [PATCH v3 5/5] mm: factor out pmd young/dirty bit handling and THP split Minchan Kim
2019-07-09 14:10 ` Michal Hocko
2019-07-10 10:56 ` Minchan Kim
2019-06-27 18:06 ` [PATCH v3 0/5] Introduce MADV_COLD and MADV_PAGEOUT Kirill A. Shutemov
2019-06-27 23:12 ` Minchan Kim
2019-07-01 7:38 ` Minchan Kim
2019-07-01 10:22 ` Michal Hocko
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=d9341eb3-08eb-3c2b-9786-00b8a4f59953@intel.com \
--to=dave.hansen@intel.com \
--cc=akpm@linux-foundation.org \
--cc=dancol@google.com \
--cc=hannes@cmpxchg.org \
--cc=hdanton@sina.com \
--cc=joel@joelfernandes.org \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lizeb@google.com \
--cc=mhocko@kernel.org \
--cc=minchan@kernel.org \
--cc=oleksandr@redhat.com \
--cc=shakeelb@google.com \
--cc=sonnyrao@google.com \
--cc=surenb@google.com \
--cc=timmurray@google.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.