linux-kernel - Re: [RFC 0/3] mm: Discard lazily freed pages when migrating

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200302142549.GO4380@dhcp22.suse.cz>
Date:   Mon, 2 Mar 2020 15:25:49 +0100
From:   Michal Hocko <mhocko@...nel.org>
To:     "Huang, Ying" <ying.huang@...el.com>
Cc:     David Hildenbrand <david@...hat.com>,
        Matthew Wilcox <willy@...radead.org>,
        Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org, Mel Gorman <mgorman@...e.de>,
        Vlastimil Babka <vbabka@...e.cz>, Zi Yan <ziy@...dia.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Minchan Kim <minchan@...nel.org>,
        Johannes Weiner <hannes@...xchg.org>,
        Hugh Dickins <hughd@...gle.com>,
        Alexander Duyck <alexander.duyck@...il.com>
Subject: Re: [RFC 0/3] mm: Discard lazily freed pages when migrating

On Mon 02-03-20 22:12:53, Huang, Ying wrote:
> Michal Hocko <mhocko@...nel.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 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.

-- 
Michal Hocko
SUSE Labs