Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Thu, 2 Apr 2020 19:04:11 -0400
From:   Daniel Jordan <daniel.m.jordan@oracle.com>
To:     Yang Shi <yang.shi@linux.alibaba.com>
Cc:     kirill.shutemov@linux.intel.com, hughd@google.com,
        aarcange@redhat.com, akpm@linux-foundation.org, linux-mm@kvack.org,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm: thp: don't need drain lru cache when splitting and
 mlocking THP
Message-ID: <20200402230411.7ckwkmd6wwtqfkm2@ca-dmjordan1.us.oracle.com>
References: <1585337380-97368-1-git-send-email-yang.shi@linux.alibaba.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1585337380-97368-1-git-send-email-yang.shi@linux.alibaba.com>
User-Agent: NeoMutt/20180716
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Sat, Mar 28, 2020 at 03:29:40AM +0800, Yang Shi wrote:
> Since the commit 8f182270dfec ("mm/swap.c: flush lru pvecs on compound
> page arrival") THP would not stay in pagevec anymore.  So the
> optimization made by commit d965432234db ("thp: increase
> split_huge_page() success rate") doesn't make sense anymore, which tries
> to unpin munlocked THPs from pagevec by draining pagevec.
> 
> And draining lru cache before isolating THP in mlock path is unnecessary
> either.

Can we get some of that nice history in this part too?

Draining lru cache before isolating THP in mlock path is also unnecessary.
b676b293fb48 ("mm, thp: fix mapped pages avoiding unevictable list on mlock")
added it and 9a73f61bdb8a ("thp, mlock: do not mlock PTE-mapped file huge
pages") accidentally carried it over after the above optimization went in.

> Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
> Cc: Hugh Dickins <hughd@google.com>
> Cc: Andrea Arcangeli <aarcange@redhat.com>
> Signed-off-by: Yang Shi <yang.shi@linux.alibaba.com>

Since we don't mlock pte-mapped THP, it seems these huge pages wouldn't ever be
in the pagevecs if I'm understanding it all.

Saves lines and some amount of overhead and lru contention, so looks good.

Reviewed-by: Daniel Jordan <daniel.m.jordan@oracle.com>