linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Vernon Yang <vernon2gm@gmail.com>
To: akpm@linux-foundation.org, david@kernel.org, lorenzo.stoakes@oracle.com
Cc: ziy@nvidia.com, npache@redhat.com, baohua@kernel.org,
	lance.yang@linux.dev, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org,
	Vernon Yang <yanglincheng@kylinos.cn>
Subject: [PATCH 0/4] Improve khugepaged scan logic
Date: Mon, 15 Dec 2025 17:04:15 +0800	[thread overview]
Message-ID: <20251215090419.174418-1-yanglincheng@kylinos.cn> (raw)

hi all,

This series is improve the khugepaged scan logic, reduce CPU consumption,
prioritize scanning task that access memory frequently.

The following data is traced by bpftrace[1] on a desktop system. After
the system has been left idle for 10 minutes upon booting, a lot of
SCAN_PMD_MAPPED or SCAN_PMD_NONE are observed during a full scan by
khugepaged.

@scan_pmd_status[1]: 1           ## SCAN_SUCCEED
@scan_pmd_status[4]: 158         ## SCAN_PMD_MAPPED
@scan_pmd_status[3]: 174         ## SCAN_PMD_NONE
total progress size: 701 MB
Total time         : 440 seconds ## include khugepaged_scan_sleep_millisecs

The khugepaged has below phenomenon: the khugepaged list is scanned in a
FIFO manner, as long as the task is not destroyed,
1. the task no longer has memory that can be collapsed into hugepage,
   continues scan it always.
2. the task at the front of the khugepaged scan list is cold, they are
   still scanned first.
3. everyone scan at intervals of khugepaged_scan_sleep_millisecs
   (default 10s). If we always scan the above two cases first, the valid
   scan will have to wait for a long time.

For the first case, when all memory has been collapsed, the mm is
automatically removed from khugepaged's scan list. If the page fault or
MADV_HUGEPAGE again, it is added back to khugepaged.

For the second case, if the user has explicitly informed us via
MADV_COLD/MADV_FREE that this memory is cold or will be freed, move mm
to khugepaged scan list tail for scan later.

The below is some performance test results.

kernbench results (testing on x86_64 machine):

                       6.18.0-baseline          6.18.0-test
Amean     user-32    18652.80 (   0.00%)    18640.85 (   0.06%)
Amean     syst-32     1165.09 (   0.00%)     1159.15 *   0.51%*
Amean     elsp-32      667.71 (   0.00%)      667.02 *   0.10%*
BAmean-95 user-32    18652.02 (   0.00%)    18638.11 (   0.07%)
BAmean-95 syst-32     1165.04 (   0.00%)     1158.41 (   0.57%)
BAmean-95 elsp-32      667.65 (   0.00%)      666.90 (   0.11%)
BAmean-99 user-32    18652.02 (   0.00%)    18638.11 (   0.07%)
BAmean-99 syst-32     1165.04 (   0.00%)     1158.41 (   0.57%)
BAmean-99 elsp-32      667.65 (   0.00%)      666.90 (   0.11%)

Create three task[2]: hot1 -> cold -> hot2. After all three task are
created, each allocate memory 128MB. the hot1/hot2 task continuously
access 128 MB memory, while the cold task only accesses its memory
briefly andthen call madvise(MADV_COLD). Here are the performance test
results:
(Throughput bigger is better, other smaller is better)

Testing on x86_64 machine:

| task hot2           | without patch | with patch    |  delta  |
|---------------------|---------------|---------------|---------|
| total accesses time |  3.14 sec     |  2.92 sec     | -7.01%  |
| cycles per access   |  4.91         |  2.07         | -57.84% |
| Throughput          |  104.38 M/sec |  112.12 M/sec | +7.42%  |
| dTLB-load-misses    |  288966432    |  1292908      | -99.55% |

Testing on qemu-system-x86_64 -enable-kvm:

| task hot2           | without patch | with patch    |  delta  |
|---------------------|---------------|---------------|---------|
| total accesses time |  3.35 sec     |  2.96 sec     | -11.64% |
| cycles per access   |  7.23         |  2.12         | -70.68% |
| Throughput          |  97.88 M/sec  |  110.76 M/sec | +13.16% |
| dTLB-load-misses    |  237406497    |  3189194      | -98.66% |

This series is based on Linux v6.18.

Thank you very much for your comments and discussions :)


[1] https://github.com/vernon2gh/app_and_module/blob/main/khugepaged/khugepaged_mm.bt
[2] https://github.com/vernon2gh/app_and_module/blob/main/khugepaged/app.c

Vernon Yang (4):
  mm: khugepaged: add trace_mm_khugepaged_scan event
  mm: khugepaged: remove mm when all memory has been collapsed
  mm: khugepaged: move mm to list tail when MADV_COLD/MADV_FREE
  mm: khugepaged: set to next mm direct when mm has
    MMF_DISABLE_THP_COMPLETELY

 include/linux/khugepaged.h         |  1 +
 include/trace/events/huge_memory.h | 24 ++++++++++++
 mm/khugepaged.c                    | 60 ++++++++++++++++++++++++------
 mm/madvise.c                       |  3 ++
 4 files changed, 76 insertions(+), 12 deletions(-)

--
2.51.0



             reply	other threads:[~2025-12-15  9:05 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-15  9:04 Vernon Yang [this message]
2025-12-15  9:04 ` [PATCH 1/4] mm: khugepaged: add trace_mm_khugepaged_scan event Vernon Yang
2025-12-18  9:24   ` David Hildenbrand (Red Hat)
2025-12-19  5:21     ` Vernon Yang
2025-12-15  9:04 ` [PATCH 2/4] mm: khugepaged: remove mm when all memory has been collapsed Vernon Yang
2025-12-15 11:52   ` Lance Yang
2025-12-16  6:27     ` Vernon Yang
2025-12-15 21:45   ` kernel test robot
2025-12-16  6:30     ` Vernon Yang
2025-12-15 23:01   ` kernel test robot
2025-12-16  6:32     ` Vernon Yang
2025-12-17  3:31   ` Wei Yang
2025-12-18  3:27     ` Vernon Yang
2025-12-18  3:48       ` Wei Yang
2025-12-18  4:41         ` Vernon Yang
2025-12-18  9:29   ` David Hildenbrand (Red Hat)
2025-12-19  5:24     ` Vernon Yang
2025-12-19  9:00       ` David Hildenbrand (Red Hat)
2025-12-19  8:35     ` Vernon Yang
2025-12-19  8:55       ` David Hildenbrand (Red Hat)
2025-12-23 11:18       ` Dev Jain
2025-12-25 16:07         ` Vernon Yang
2025-12-29  6:02         ` Vernon Yang
2025-12-22 19:00   ` kernel test robot
2025-12-15  9:04 ` [PATCH 3/4] mm: khugepaged: move mm to list tail when MADV_COLD/MADV_FREE Vernon Yang
2025-12-15 21:12   ` kernel test robot
2025-12-16  7:00     ` Vernon Yang
2025-12-16 13:08   ` kernel test robot
2025-12-16 13:31   ` kernel test robot
2025-12-18  9:31   ` David Hildenbrand (Red Hat)
2025-12-19  5:29     ` Vernon Yang
2025-12-19  8:58       ` David Hildenbrand (Red Hat)
2025-12-21  2:10         ` Wei Yang
2025-12-21  4:25           ` Vernon Yang
2025-12-21  9:24             ` David Hildenbrand (Red Hat)
2025-12-21 12:34               ` Vernon Yang
2025-12-23  9:59                 ` David Hildenbrand (Red Hat)
2025-12-25 15:12                   ` Vernon Yang
2025-12-21 12:38             ` Wei Yang
2025-12-15  9:04 ` [PATCH 4/4] mm: khugepaged: set to next mm direct when mm has MMF_DISABLE_THP_COMPLETELY Vernon Yang
2025-12-18  9:33   ` David Hildenbrand (Red Hat)
2025-12-19  5:31     ` Vernon Yang

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=20251215090419.174418-1-yanglincheng@kylinos.cn \
    --to=vernon2gm@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=baohua@kernel.org \
    --cc=david@kernel.org \
    --cc=lance.yang@linux.dev \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lorenzo.stoakes@oracle.com \
    --cc=npache@redhat.com \
    --cc=yanglincheng@kylinos.cn \
    --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