Received-SPF: pass (google.com: domain of linux-kernel+bounces-148762-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Date: Wed, 17 Apr 2024 16:08:55 +0100
From: Matthew Wilcox <willy@infradead.org>
To: Lance Yang <ioworker0@gmail.com>
Cc: akpm@linux-foundation.org, maskray@google.com, ziy@nvidia.com,
	ryan.roberts@arm.com, david@redhat.com, 21cnbao@gmail.com,
	mhocko@suse.com, fengwei.yin@intel.com, zokeefe@google.com,
	shy828301@gmail.com, xiehuan09@gmail.com,
	wangkefeng.wang@huawei.com, songmuchun@bytedance.com,
	peterx@redhat.com, minchan@kernel.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/1] mm/vmscan: avoid split PMD-mapped THP during
 shrink_folio_list()
Message-ID: <Zh_mBxJmYe6eCA29@casper.infradead.org>
References: <20240417141111.77855-1-ioworker0@gmail.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20240417141111.77855-1-ioworker0@gmail.com>

On Wed, Apr 17, 2024 at 10:11:11PM +0800, Lance Yang wrote:
> When the user no longer requires the pages, they would use madvise(madv_free)
> to mark the pages as lazy free. IMO, they would not typically rewrite to the
> given range.
> 
> At present, a PMD-mapped THP marked as lazyfree during shrink_folio_list()
> is unconditionally split, which may be unnecessary. If the THP is exclusively
> mapped and clean, and the PMD associated with it is also clean, then we can
> attempt to remove the PMD mapping from it. This change will improve the
> efficiency of memory reclamation in this case.
> 
> On an Intel i5 CPU, reclaiming 1GiB of PMD-mapped THPs using
> mem_cgroup_force_empty() results in the following runtimes in seconds
> (shorter is better):
> 
> --------------------------------------------
> |     Old       |      New       |  Change  |
> --------------------------------------------
> |   0.683426    |    0.049197    |  -92.80% |
> --------------------------------------------
> 
> Signed-off-by: Lance Yang <ioworker0@gmail.com>
> ---
>  include/linux/huge_mm.h |  1 +
>  include/linux/rmap.h    |  1 +
>  mm/huge_memory.c        |  2 +-
>  mm/rmap.c               | 81 +++++++++++++++++++++++++++++++++++++++++
>  mm/vmscan.c             |  7 ++++
>  5 files changed, 91 insertions(+), 1 deletion(-)

I'm confused why we need all this extra code.  If we remove a folio
from the pagecache, we can just call truncate_inode_folio() and
unmap_mapping_folio() takes care of all the necessary unmappings.
Why can't you call unmap_mapping_folio() here?