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]

Date:   Thu, 05 Mar 2020 09:42:52 +0800
From:   "Huang\, Ying" <ying.huang@...el.com>
To:     Mel Gorman <mgorman@...e.de>
Cc:     Michal Hocko <mhocko@...nel.org>,
        David Hildenbrand <david@...hat.com>,
        Johannes Weiner <hannes@...xchg.org>,
        Matthew Wilcox <willy@...radead.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        <linux-mm@...ck.org>, <linux-kernel@...r.kernel.org>,
        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>,
        Hugh Dickins <hughd@...gle.com>,
        Alexander Duyck <alexander.duyck@...il.com>
Subject: Re: [RFC 0/3] mm: Discard lazily freed pages when migrating

Mel Gorman <mgorman@...e.de> writes:

> On Wed, Mar 04, 2020 at 10:58:02AM +0100, Michal Hocko wrote:
>> > >> If my understanding were correct, the newly migrated clean MADV_FREE
>> > >> pages will be put at the head of inactive file LRU list instead of the
>> > >> tail.  So it's possible that some useful file cache pages will be
>> > >> reclaimed.
>> > >
>> > > This is the case also when you migrate other pages, right? We simply
>> > > cannot preserve the aging.
>> > 
>> > So you consider the priority of the clean MADV_FREE pages is same as
>> > that of page cache pages?
>> 
>> This is how MADV_FREE has been implemented, yes. See f7ad2a6cb9f7 ("mm:
>> move MADV_FREE pages into LRU_INACTIVE_FILE list") for the
>> justification.
>> 
>> > Because the penalty difference is so large, I
>> > think it may be a good idea to always put clean MADV_FREE pages at the
>> > tail of the inactive file LRU list?
>> 
>> You are again making assumptions without giving any actual real
>> examples. Reconstructing MADV_FREE pages cost can differ a lot. This
>> really depends on the specific usecase. Moving pages to the tail of LRU
>> would make them the primary candidate for the reclaim with a strange
>> LIFO semantic. Adding them to the head might be not the universal win
>> but it will at least provide a reasonable FIFO semantic. I also find
>> it much more easier to reason about MADV_FREE as an inactive cache.
>
> I tend to agree, that would make MADV_FREE behave more like a
> PageReclaim page that gets tagged for immediate reclaim when writeback
> completes. Immediate reclaim is in response to heavy memory pressure where
> there is trouble finding clean file pages to reclaim and dirty/writeback
> pages are getting artifically preserved over hot-but-clean file
> pages. That is a clear inversion of the order pages should be reclaimed
> and is justified.  While there *might* be a basis for reclaiming MADV_FREE
> sooner rather than later, there would have to be some evidence of a Page
> inversion problem where a known hot page was getting reclaimed before
> MADV_FREE pages. For example, it could easily be considered a bug to free
> MADV_FREE pages over a page that was last touched at boot time.

Yes.  This sounds reasonable.  Although the current solution isn't
perfect, it can avoid the really bad situation as above.

Best Regards,
Huang, Ying