linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] mm: thp: don't need drain lru cache when splitting and mlocking THP
@ 2020-03-27 19:29 Yang Shi
  2020-04-02 23:04 ` Daniel Jordan
  2020-04-03 14:35 ` Kirill A. Shutemov
  0 siblings, 2 replies; 7+ messages in thread
From: Yang Shi @ 2020-03-27 19:29 UTC (permalink / raw)
  To: kirill.shutemov, hughd, aarcange, akpm; +Cc: yang.shi, linux-mm, linux-kernel

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.

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>
---
 mm/huge_memory.c | 7 -------
 1 file changed, 7 deletions(-)

diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index b08b199..1af2e7d6 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -1527,7 +1527,6 @@ struct page *follow_trans_huge_pmd(struct vm_area_struct *vma,
 			goto skip_mlock;
 		if (!trylock_page(page))
 			goto skip_mlock;
-		lru_add_drain();
 		if (page->mapping && !PageDoubleMap(page))
 			mlock_vma_page(page);
 		unlock_page(page);
@@ -2711,7 +2710,6 @@ int split_huge_page_to_list(struct page *page, struct list_head *list)
 	struct anon_vma *anon_vma = NULL;
 	struct address_space *mapping = NULL;
 	int count, mapcount, extra_pins, ret;
-	bool mlocked;
 	unsigned long flags;
 	pgoff_t end;
 
@@ -2770,14 +2768,9 @@ int split_huge_page_to_list(struct page *page, struct list_head *list)
 		goto out_unlock;
 	}
 
-	mlocked = PageMlocked(head);
 	unmap_page(head);
 	VM_BUG_ON_PAGE(compound_mapcount(head), head);
 
-	/* Make sure the page is not on per-CPU pagevec as it takes pin */
-	if (mlocked)
-		lru_add_drain();
-
 	/* prevent PageLRU to go away from under us, and freeze lru stats */
 	spin_lock_irqsave(&pgdata->lru_lock, flags);
 
-- 
1.8.3.1



^ permalink raw reply related	[flat|nested] 7+ messages in thread

* Re: [PATCH] mm: thp: don't need drain lru cache when splitting and mlocking THP
  2020-03-27 19:29 [PATCH] mm: thp: don't need drain lru cache when splitting and mlocking THP Yang Shi
@ 2020-04-02 23:04 ` Daniel Jordan
  2020-04-02 23:14   ` Yang Shi
  2020-04-02 23:17   ` Daniel Jordan
  2020-04-03 14:35 ` Kirill A. Shutemov
  1 sibling, 2 replies; 7+ messages in thread
From: Daniel Jordan @ 2020-04-02 23:04 UTC (permalink / raw)
  To: Yang Shi; +Cc: kirill.shutemov, hughd, aarcange, akpm, linux-mm, linux-kernel

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>


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] mm: thp: don't need drain lru cache when splitting and mlocking THP
  2020-04-02 23:04 ` Daniel Jordan
@ 2020-04-02 23:14   ` Yang Shi
  2020-04-02 23:17   ` Daniel Jordan
  1 sibling, 0 replies; 7+ messages in thread
From: Yang Shi @ 2020-04-02 23:14 UTC (permalink / raw)
  To: Daniel Jordan
  Cc: kirill.shutemov, hughd, aarcange, akpm, linux-mm, linux-kernel



On 4/2/20 4:04 PM, 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.

Thanks for finding out this, I didn't dig that far. Will add it into v2.

>
>> 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.

Yes, it is correct.

>
> Saves lines and some amount of overhead and lru contention, so looks good.
>
> Reviewed-by: Daniel Jordan <daniel.m.jordan@oracle.com>

Thanks.



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] mm: thp: don't need drain lru cache when splitting and mlocking THP
  2020-04-02 23:04 ` Daniel Jordan
  2020-04-02 23:14   ` Yang Shi
@ 2020-04-02 23:17   ` Daniel Jordan
  2020-04-02 23:37     ` Yang Shi
  1 sibling, 1 reply; 7+ messages in thread
From: Daniel Jordan @ 2020-04-02 23:17 UTC (permalink / raw)
  To: Yang Shi; +Cc: kirill.shutemov, hughd, aarcange, akpm, linux-mm, linux-kernel

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@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.

Actually pte-mapped THP doesn't matter for this, both paths always drain when
they're working with pmd-mapped THP.


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] mm: thp: don't need drain lru cache when splitting and mlocking THP
  2020-04-02 23:17   ` Daniel Jordan
@ 2020-04-02 23:37     ` Yang Shi
  2020-04-03 13:12       ` Daniel Jordan
  0 siblings, 1 reply; 7+ messages in thread
From: Yang Shi @ 2020-04-02 23:37 UTC (permalink / raw)
  To: Daniel Jordan
  Cc: kirill.shutemov, hughd, aarcange, akpm, linux-mm, linux-kernel



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@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.
> 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.



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] mm: thp: don't need drain lru cache when splitting and mlocking THP
  2020-04-02 23:37     ` Yang Shi
@ 2020-04-03 13:12       ` Daniel Jordan
  0 siblings, 0 replies; 7+ messages in thread
From: Daniel Jordan @ 2020-04-03 13:12 UTC (permalink / raw)
  To: Yang Shi
  Cc: Daniel Jordan, kirill.shutemov, hughd, aarcange, akpm, linux-mm,
	linux-kernel

On Thu, Apr 02, 2020 at 04:37:06PM -0700, Yang Shi wrote:
> 
> 
> 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@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.
> > 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.

Ah, that's right!  The checks in swap.c are for PageCompound.


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] mm: thp: don't need drain lru cache when splitting and mlocking THP
  2020-03-27 19:29 [PATCH] mm: thp: don't need drain lru cache when splitting and mlocking THP Yang Shi
  2020-04-02 23:04 ` Daniel Jordan
@ 2020-04-03 14:35 ` Kirill A. Shutemov
  1 sibling, 0 replies; 7+ messages in thread
From: Kirill A. Shutemov @ 2020-04-03 14:35 UTC (permalink / raw)
  To: Yang Shi; +Cc: kirill.shutemov, hughd, aarcange, akpm, linux-mm, linux-kernel

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.
> 
> 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>

Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>

-- 
 Kirill A. Shutemov


^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2020-04-03 14:36 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-03-27 19:29 [PATCH] mm: thp: don't need drain lru cache when splitting and mlocking THP Yang Shi
2020-04-02 23:04 ` Daniel Jordan
2020-04-02 23:14   ` Yang Shi
2020-04-02 23:17   ` Daniel Jordan
2020-04-02 23:37     ` Yang Shi
2020-04-03 13:12       ` Daniel Jordan
2020-04-03 14:35 ` Kirill A. Shutemov

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).