[0/2] Reduce lock contention related with large folio

Message

Yin Fengwei April 17, 2023, 7:56 a.m. UTC

Ryan tried to enable the large folio for anonymous mapping [1].

Unlike large folio for page cache which doesn't trigger frequent page
allocation/free, large folio for anonymous mapping is allocated/freeed
more frequently. So large folio for anonymous mapping exposes some lock
contention.

Ryan mentioned the deferred queue lock in [1]. We also met other two
lock contention: lru lock and zone lock.

This series tries to mitigate the deferred queue lock and reduce lru
lock in some level.

The patch1 tries to reduce deferred queue lock by not acquiring queue
lock when check whether the folio is in deferred list or not. Test
page fault1 of will-it-scale showed 60% deferred queue lock contention
reduction.

The patch2 tries to reduce lru lock by allowing batched add large folio
to lru list. Test page fault1 of will-it-scale showed 20% lru lock
contention reduction.

The zone lock contention happens on large folio free path and related
with commit f26b3fa04611 "mm/page_alloc: limit number of high-order
pages on PCP during bulk free" and will not be address by this series.


[1]
https://lore.kernel.org/linux-mm/[e-mail]/

Yin Fengwei (2):
  THP: avoid lock when check whether THP is in deferred list
  lru: allow large batched add large folio to lru list

 include/linux/pagevec.h | 19 +++++++++++++++++--
 mm/huge_memory.c        | 19 ++++++++++++++++---
 mm/swap.c               |  3 +--
 3 files changed, 34 insertions(+), 7 deletions(-)

Comments

Ryan Roberts April 17, 2023, 10:33 a.m. UTC | #1

On 17/04/2023 08:56, Yin Fengwei wrote:
> Ryan tried to enable the large folio for anonymous mapping [1].
> 
> Unlike large folio for page cache which doesn't trigger frequent page
> allocation/free, large folio for anonymous mapping is allocated/freeed
> more frequently. So large folio for anonymous mapping exposes some lock
> contention.
> 
> Ryan mentioned the deferred queue lock in [1]. We also met other two
> lock contention: lru lock and zone lock.
> 
> This series tries to mitigate the deferred queue lock and reduce lru
> lock in some level.
> 
> The patch1 tries to reduce deferred queue lock by not acquiring queue
> lock when check whether the folio is in deferred list or not. Test
> page fault1 of will-it-scale showed 60% deferred queue lock contention
> reduction.
> 
> The patch2 tries to reduce lru lock by allowing batched add large folio
> to lru list. Test page fault1 of will-it-scale showed 20% lru lock
> contention reduction.
> 
> The zone lock contention happens on large folio free path and related
> with commit f26b3fa04611 "mm/page_alloc: limit number of high-order
> pages on PCP during bulk free" and will not be address by this series.

I applied this series on top of mine and did some quick perf tests. See
https://lore.kernel.org/linux-mm/[e-mail]/.
The change is certainly reducing time spent in the kernel, but there are other
problems I'll need to investigate. So:

Tested-by: Ryan Roberts <[e-mail]>

Thanks,
Ryan

> 
> 
> [1]
> https://lore.kernel.org/linux-mm/[e-mail]/
> 
> Yin Fengwei (2):
>   THP: avoid lock when check whether THP is in deferred list
>   lru: allow large batched add large folio to lru list
> 
>  include/linux/pagevec.h | 19 +++++++++++++++++--
>  mm/huge_memory.c        | 19 ++++++++++++++++---
>  mm/swap.c               |  3 +--
>  3 files changed, 34 insertions(+), 7 deletions(-)
>