mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "David Hildenbrand (Arm)" <david@kernel.org>
To: "Barry Song (Xiaomi)" <baohua@kernel.org>,
	akpm@linux-foundation.org, linux-mm@kvack.org
Cc: linux-kernel@vger.kernel.org, Lorenzo Stoakes <ljs@kernel.org>,
	Zi Yan <ziy@nvidia.com>,
	Baolin Wang <baolin.wang@linux.alibaba.com>,
	"Liam R . Howlett" <liam@infradead.org>,
	Nico Pache <npache@redhat.com>,
	Ryan Roberts <ryan.roberts@arm.com>, Dev Jain <dev.jain@arm.com>,
	Lance Yang <lance.yang@linux.dev>
Subject: Re: [RFC PATCH] mm: allow smaller large folios to use lru_cache
Date: Thu, 2 Jul 2026 15:00:08 +0200	[thread overview]
Message-ID: <6a81273c-6d5c-4811-a6a6-e1e8a3a47b97@kernel.org> (raw)
In-Reply-To: <20260702122342.26721-1-baohua@kernel.org>

On 7/2/26 14:23, Barry Song (Xiaomi) wrote:
> For a system which primarily uses smaller orders for large folios,
> it could be beneficial to enable lru_cache to avoid lock contention.
> 
> For large folios with higher orders, the number of folios involved
> would be small, so the contention is less significant.
> 
> The following small program runs on a system with 16 KiB
> mTHP enabled.
> 
>  #include <pthread.h>
>  #include <sys/mman.h>
>  #include <string.h>
> 
>  #define NUM_THREADS     20
>  #define MEM_SIZE        (16 * 1024 * 1024)
>  #define LOOP_COUNT      1000
> 
>  void* thread_worker(void* arg) {
>      void *addr = mmap(NULL, MEM_SIZE, PROT_READ | PROT_WRITE,
>                        MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
> 
>      for (int i = 0; i < LOOP_COUNT; i++) {
>          memset(addr, 0x55, MEM_SIZE);
>          madvise(addr, MEM_SIZE, MADV_DONTNEED);
>      }
> 
>      munmap(addr, MEM_SIZE);
>      pthread_exit(NULL);
>  }
> 
>  int main() {
>      pthread_t threads[NUM_THREADS];
> 
>      for (long t = 0; t < NUM_THREADS; t++) {
>          pthread_create(&threads[t], NULL, thread_worker, (void*)t);
>      }
> 
>      for (int t = 0; t < NUM_THREADS; t++) {
>          pthread_join(threads[t], NULL);
>      }
> 
>      return 0;
>  }
> 
> Before patch:
> root@barry-desktop:/home/barry# time ./a.out
> 
> real	0m20.233s
> user	0m21.739s
> sys	6m21.143s
> 
> Perf lock report:
>       Name   acquired  contended     avg wait   total wait     max wait     min wait
> 
>              21158662   21158662     29.20 us     10.30 m      67.83 us       884 ns
>                 13547      13547     14.68 us    198.93 ms    135.39 us       982 ns
>  rcu_state         41         41      1.83 us     75.21 us      3.46 us      1.27 us
>  rcu_state         34         34      1.83 us     62.09 us      2.60 us      1.16 us
>                     5          5     21.31 us    106.57 us     25.77 us     18.17 us
>                     5          5      3.01 us     15.07 us      5.19 us      1.53 us
>                     3          3      6.42 us     19.26 us      9.63 us      4.22 us
>                     3          3      4.20 us     12.61 us      7.45 us      2.10 us
>                     2          2      5.03 us     10.06 us      7.88 us      2.18 us
>                     2          2      2.79 us      5.59 us      3.34 us      2.25 us
>                     1          1      4.70 us      4.70 us      4.70 us      4.70 us
>                     1          1      9.77 us      9.77 us      9.77 us      9.77 us
> 
> After patch:
> root@barry-desktop:/home/barry# time ./a.out
> 
> real	0m17.796s
> user	0m24.962s
> sys	5m28.774s
> 
> Perf lock report:
>       Name   acquired  contended     avg wait   total wait     max wait     min wait
> 
>               1407013    1407013     25.44 us     35.80 s     127.83 us       972 ns
>                845113     845113     47.96 us     40.54 s     152.86 us      1.21 us
>  rcu_state       1920       1920      5.87 us     11.27 ms     25.02 us      1.76 us
>  rcu_state       1889       1889      5.80 us     10.96 ms     30.35 us      1.61 us
>                   140        140      3.97 us    555.52 us     12.51 us      1.20 us
>                    10         10     61.34 us    613.42 us     96.90 us     44.48 us
>                     8          8     24.03 us    192.26 us     37.64 us      6.95 us
>                     8          8     12.32 us     98.56 us     25.55 us      4.16 us
> 
> Both system time and lock contention are noticeably reduced.
> 
> Cc: David Hildenbrand <david@kernel.org>
> Cc: Lorenzo Stoakes <ljs@kernel.org>
> Cc: Zi Yan <ziy@nvidia.com>
> Cc: Baolin Wang <baolin.wang@linux.alibaba.com>
> Cc: Liam R. Howlett <liam@infradead.org>
> Cc: Nico Pache <npache@redhat.com>
> Cc: Ryan Roberts <ryan.roberts@arm.com>
> Cc: Dev Jain <dev.jain@arm.com>
> Cc: Lance Yang <lance.yang@linux.dev>
> Signed-off-by: Barry Song (Xiaomi) <baohua@kernel.org>
> ---
>  include/linux/swap.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/include/linux/swap.h b/include/linux/swap.h
> index 8f0f68e245ba..fce1d84aa2c8 100644
> --- a/include/linux/swap.h
> +++ b/include/linux/swap.h
> @@ -322,9 +322,9 @@ static inline bool folio_may_be_lru_cached(struct folio *folio)
>  	/*
>  	 * Holding PMD-sized folios in per-CPU LRU cache unbalances accounting.
>  	 * Holding small numbers of low-order mTHP folios in per-CPU LRU cache
> -	 * will be sensible, but nobody has implemented and tested that yet.
> +	 * will be sensible.
>  	 */
> -	return !folio_test_large(folio);
> +	return folio_order(folio) < PAGE_ALLOC_COSTLY_ORDER;
>  }
>  
>  extern atomic_t lru_disable_count;

Not that __wp_can_reuse_large_anon_folio() currently assumes that large folios
are not in the LRU cache.

-- 
Cheers,

David

  reply	other threads:[~2026-07-02 13:00 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-02 12:23 Barry Song (Xiaomi)
2026-07-02 13:00 ` David Hildenbrand (Arm) [this message]
2026-07-06  9:51   ` Barry Song

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6a81273c-6d5c-4811-a6a6-e1e8a3a47b97@kernel.org \
    --to=david@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=baohua@kernel.org \
    --cc=baolin.wang@linux.alibaba.com \
    --cc=dev.jain@arm.com \
    --cc=lance.yang@linux.dev \
    --cc=liam@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=ljs@kernel.org \
    --cc=npache@redhat.com \
    --cc=ryan.roberts@arm.com \
    --cc=ziy@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome