Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Sun, 6 Mar 2022 14:07:40 -0800 (PST)
From:   David Rientjes <rientjes@google.com>
To:     Hugh Dickins <hughd@google.com>
cc:     Andrew Morton <akpm@linux-foundation.org>,
        Alex Shi <alexs@kernel.org>,
        Alexander Duyck <alexander.duyck@gmail.com>,
        linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH mmotm] mm: __isolate_lru_page_prepare() in
 isolate_migratepages_block()
In-Reply-To: <879d62a8-91cc-d3c6-fb3b-69768236df68@google.com>
Message-ID: <f77de36f-32f3-9036-98b0-d07d851b8e0@google.com>
References: <879d62a8-91cc-d3c6-fb3b-69768236df68@google.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Precedence: bulk

On Fri, 4 Mar 2022, Hugh Dickins wrote:

> __isolate_lru_page_prepare() conflates two unrelated functions, with
> the flags to one disjoint from the flags to the other; and hides some
> of the important checks outside of isolate_migratepages_block(), where
> the sequence is better to be visible.  It comes from the days of lumpy
> reclaim, before compaction, when the combination made more sense.
> 
> Move what's needed by mm/compaction.c isolate_migratepages_block() inline
> there, and what's needed by mm/vmscan.c isolate_lru_pages() inline there.
> 
> Shorten "isolate_mode" to "mode", so the sequence of conditions is easier
> to read.  Declare a "mapping" variable, to save one call to page_mapping()
> (but not another: calling again after page is locked is necessary).
> Simplify isolate_lru_pages() with a "move_to" list pointer.
> 
> Signed-off-by: Hugh Dickins <hughd@google.com>

Acked-by: David Rientjes <rientjes@google.com>