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:   Mon, 4 Oct 2021 10:10:37 +0100
From:   Mel Gorman <mgorman@techsingularity.net>
To:     "Matthew Wilcox (Oracle)" <willy@infradead.org>
Cc:     Andrew Morton <akpm@linux-foundation.org>, linux-mm@kvack.org,
        linux-kernel@vger.kernel.org
Subject: Re: [RFC] mm: Optimise put_pages_list()
Message-ID: <20211004091037.GM3959@techsingularity.net>
References: <20210930163258.3114404-1-willy@infradead.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15
Content-Disposition: inline
In-Reply-To: <20210930163258.3114404-1-willy@infradead.org>
User-Agent: Mutt/1.10.1 (2018-07-13)
Precedence: bulk

On Thu, Sep 30, 2021 at 05:32:58PM +0100, Matthew Wilcox (Oracle) wrote:
> Instead of calling put_page() one page at a time, pop pages off
> the list if there are other refcounts and pass the remainder
> to free_unref_page_list().  This should be a speed improvement,
> but I have no measurements to support that.  It's also not very
> widely used today, so I can't say I've really tested it.  I'm only
> bothering with this patch because I'd like the IOMMU code to use it
> https://lore.kernel.org/lkml/20210930162043.3111119-1-willy@infradead.org/
> 
> Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>

I see your motivation but you need to check that all users of
put_pages_list (current and future) handle destroy_compound_page properly
or handle it within put_pages_list. For example, the release_pages()
user of free_unref_page_list calls __put_compound_page directly before
freeing. put_pages_list as it stands will call dstroy_compound_page but
free_unref_page_list does not destroy compound pages in free_pages_prepare

-- 
Mel Gorman
SUSE Labs