Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) client-ip=2620:137:e000::3:8;
Date:   Mon, 6 Nov 2023 13:35:40 -0800
From:   Andrew Morton <akpm@linux-foundation.org>
To:     Zhiguo Jiang <justinjiang@vivo.com>
Cc:     linux-mm@kvack.org, linux-kernel@vger.kernel.org,
        opensource.kernel@vivo.com
Subject: Re: [PATCH v2 1/2] mm:vmscan: the dirty folio in folio list skip
 unmap
Message-Id: <20231106133540.0d985052fa9137136593cbde@linux-foundation.org>
In-Reply-To: <20231019134211.329-2-justinjiang@vivo.com>
References: <20231019134211.329-1-justinjiang@vivo.com>
        <20231019134211.329-2-justinjiang@vivo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Precedence: bulk

On Thu, 19 Oct 2023 21:42:10 +0800 Zhiguo Jiang <justinjiang@vivo.com> wrote:

> In the shrink_folio_list() the sources of the file dirty folio include
> two ways below:
> 1. The dirty folio is from the incoming parameter folio_list,
>    which is the inactive file lru.
> 2. The dirty folio is from the PTE dirty bit transferred by
>    the try_to_unmap().
> 
> For the first source of the dirty folio, if the dirty folio does not
> support pageout, the dirty folio can skip unmap in advance to reduce
> recyling time.
> 

This patch does an amount of code movement and it implements a
functional change.

Is it possible to split these?  The first patch moves code around but
has no runtime effect, the second patch implements the functional
change.

Also, the patch doesn't apply to current code so please redo it against
Linus's latest tree?

Thanks.