On 4/2/20 4:17 PM, Daniel Jordan wrote:
On Thu, Apr 02, 2020 at 07:04:11PM -0400, Daniel Jordan wrote:
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@xxxxxxxxxxxxxxx>
Cc: Hugh Dickins <hughd@xxxxxxxxxx>
Cc: Andrea Arcangeli <aarcange@xxxxxxxxxx>
Signed-off-by: Yang Shi <yang.shi@xxxxxxxxxxxxxxxxx>
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.
Actually pte-mapped THP doesn't matter for this, both paths always drain when
they're working with pmd-mapped THP.
Actually either pte-mapped or pmd-mapped doesn't matter, as long as it
is compound page the lru cache would be flushed immediately upon the
arrival of the compound page.
