Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Tue, 21 Sep 2021 10:48:19 -0400
From:   Johannes Weiner <hannes@cmpxchg.org>
To:     Yongmei Xie <yongmeixie@hotmail.com>
Cc:     akpm@linux-foundation.org, linux-mm@kvack.org,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm:vmscan: fix extra adjustment for lruvec's
 nonresident_age in case of reactivation
Message-ID: <YUnwsyE87TViMNMz@cmpxchg.org>
References: <TYCP286MB1108D012DA436CA72029ACA7C5DF9@TYCP286MB1108.JPNP286.PROD.OUTLOOK.COM>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <TYCP286MB1108D012DA436CA72029ACA7C5DF9@TYCP286MB1108.JPNP286.PROD.OUTLOOK.COM>
Precedence: bulk

On Sun, Sep 19, 2021 at 11:25:09PM +0800, Yongmei Xie wrote:
> Before commit #31d8fcac, VM didn't increase nonresident_age (AKA inactive age for
> file pages) in shrink_page_list. When putback_inactive_pages was converged with
> move_pages_to_lru, both shrink_active_list and shrink_page_list use the same
> function to handle move pages to the appropriate lru under lru lock's protection.
> 
> At those day, VM didn't increase nonresident_age for second chance promotion.
> Commit #31d8fcac fix the problem. Definitely, we should account the activation
> for second chance. But move_pages_to_lru is used in reactivation in active lru
> as well for protecting code section. So I suggest to add another variable to
> tell whether reactivation or not.

This looks incorrect to me. We *should* count reactivations/rotations
on the active list toward nonresident age.

The nonresident age tracks the number of in-memory references in order
to later calculate the (minimum) reuse distance of refaulting pages.

If a page on the active list gets reactivated due to a reference, that
reference contributes to the distance of yet-to-refault pages.