mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Bharata B Rao <bharata@amd.com>
To: <linux-kernel@vger.kernel.org>, <linux-mm@kvack.org>
Cc: <tglx@kernel.org>, <mingo@redhat.com>, <bp@alien8.de>,
	<dave.hansen@linux.intel.com>, <x86@kernel.org>, <hpa@zytor.com>,
	<xin@zytor.com>, <luto@kernel.org>, <peterz@infradead.org>,
	<Jonathan.Cameron@huawei.com>, <gourry@gourry.net>,
	<rientjes@google.com>, <sj@kernel.org>, <weixugc@google.com>,
	<willy@infradead.org>, <ying.huang@linux.alibaba.com>,
	<ziy@nvidia.com>, <dave@stgolabs.net>, <nifan.cxl@gmail.com>,
	<xuezhengchu@huawei.com>, <yiannis@zptcorp.com>,
	<akpm@linux-foundation.org>, <david@kernel.org>,
	<byungchul@sk.com>, <kinseyho@google.com>,
	<joshua.hahnjy@gmail.com>, <yuanchu@google.com>,
	<balbirs@nvidia.com>, <shivankg@amd.com>,
	<donettom@linux.ibm.com>, <linyongting@bytedance.com>
Subject: Re: [RFC PATCH v0 0/3] pghot: x86: IBS Memory Profiler for hot page promotion
Date: Thu, 24 Sep 2026 12:01:00 +0530	[thread overview]
Message-ID: <1928da1c-e07e-4523-98b6-611b62a53143@amd.com> (raw)
In-Reply-To: <20260924062206.319314-1-bharata@amd.com>

On 24-Sep-26 11:52 AM, Bharata B Rao wrote:
> 
> Detailed per-benchmark tables (throughput/latency + vmstat and pghot
> promotion counters) are posted as replies to this thread.
Benchmark
----------------------------------------------------------------------
NAS Parallel Benchmark BT (Block Tri-diagonal solver), MPI version,
Class D, 16 ranks. Compute threads are bound to node 1 via:

  /usr/bin/mpirun -np 16 /usr/bin/numactl --cpunodebind=1 \
      .../NPB3.4.4/NPB3.4-MPI/bin/bt.F.x

Test system : 3 NUMA nodes. Nodes 0 and 1 are top-tier DRAM
with CPUs (~252 GiB each); node 2 is a CPU-less CXL lower tier
(~252 GiB). Node distances: 0<->1 = 12, 1<->2 = 50. Before the
measurement phase all provisioned memory (~161.4 GiB across ranks)
is migrated to the CXL node 2, then ranks resume and measurement
begins, so the run starts fully cold on slow memory. This isolates
the effect of hot-page promotion (node 2 -> node 1) on a
bandwidth/latency-sensitive workload.

Kernels
----------------------------------------------------------------------
  base  = 7.3.0-rc2-base+   (mainline base)
  pghot = 7.3.0-rc2-pghot+  (pghot + AMD IBS Memory Profiler)

Legend
----------------------------------------------------------------------
  A = base-numab0    Base kernel, NO tiering (numa_balancing=0);
                     reference case
  B = base-numab2    Base kernel, kernel NUMA-balancing tiering
                     (numa_balancing=2, hint-fault driven promotion,
                     demotion enabled)
  C = pghot-hwhints  pghot kernel, promotion driven by the AMD IBS
                     Memory Profiler (hardware access sampling);
                     numa_balancing=0 (no NUMA hint faults / scanning)

IBS Memory Profiler configuration (run C)
----------------------------------------------------------------------
  vm.pghot_enabled_sources     = 2   (HWHINTS source)
  vm.pghot_target_nid          = 1   (promote to compute node 1,
                                       same target NUMAB2 uses)
  vm.pghot_freq_threshold      = 1   (promote on 1st access, like
                                       NUMAB2)
  vm.pghot_promote_rate_limit_MBps = 65536
  vm.pghot_promote_window_ms       = 3000
  /sys/devices/system/cpu/ibs-mprof/enabled = enabled
  ibs-mprof: period=10000, l3miss-only=1, lat-thresh=0, lat-filter=0

Table 1a - Runtime (lower is better)
----------------------------------------------------------------------
Metric                           A           B           C
----------------------------------------------------------------------
NPB Time (s)               7564.04     3232.04     3515.97
Speedup vs A (time)           1.00        2.34        2.15

Table 1b - Throughput (higher is better)
----------------------------------------------------------------------
Metric                           A           B           C
----------------------------------------------------------------------
NPB Mop/s total           51739.90   121088.51   111310.01
Mop/s ratio vs A              1.00        2.34        2.15
Mop/s ratio vs B              0.43        1.00        0.92
Peak prov. mem (GiB)        161.38      161.38      161.38

Table 2 - vmstat counter deltas (after - before measurement window)
----------------------------------------------------------------------
Counter                               A           B           C
----------------------------------------------------------------------
pgpromote_success                     0    42181004    39701482
pgpromote_candidate                   0           0           0
pgpromote_candidate_nrl               0    42181008    39702291
pgdemote_kswapd                       0           0           0
pgdemote_direct                       0           0           0
numa_pte_updates                      0    42252137           0
numa_hint_faults                      0    42182619           0
numa_pages_migrated                   0    42182610    39701482
pgmigrate_success                     0    42182610    39701482
pghot_recorded_accesses               0           0    39793839
pghot_reported_hintfaults             0           0           0
pghot_reported_hwhints                0           0   553943841
hwhint_total_events                   0           0   553950006
hwhint_dram_accesses                  0           0   514144414
hwhint_extmem_accesses                0           0    39794778
hwhint_cache_accesses                 0           0           0
hwhint_useful_events                  0           0   553943842
hwhint_dropped_events                 0           0        6147

Key observations
----------------------------------------------------------------------
1. Tiering is essential for BT. With the whole footprint pinned to
   the CXL lower tier and no promotion (A), BT is 2.34x slower than
   kernel NUMA-balancing tiering (7564 vs 3232 s) and delivers less
   than half the throughput (51.7k vs 121.1k Mop/s). BT is
   bandwidth/latency-bound and much of its footprint is genuinely
   hot, so promotion back to DRAM helps a lot.

2. IBS Memory Profiler drives effective promotion WITHOUT NUMA
   balancing. Run C reaches 3516 s / 111.3k Mop/s = 2.15x over the
   no-tiering baseline, i.e. ~92% of NUMAB2's throughput, while
   numa_pte_updates and numa_hint_faults are both 0 -- no PTE
   scanning and no hint faults are involved. Promotion is instead
   fed entirely by hardware access samples.

3. Comparable migration volume, different mechanism. C promotes
   ~39.70M pages (pgpromote_success == pgmigrate_success ==
   numa_pages_migrated) vs ~42.18M for NUMAB2 (B) -- about 6% fewer,
   consistent with the ~9% runtime gap. Both promote to node 1.

4. IBS sampling is high-volume but precise. With period=10000 and
   l3miss-only=1, the profiler recorded ~554M useful events
   (hwhint_useful_events / pghot_reported_hwhints = 553,943,84x).
   Of ~554M total events, ~514M were DRAM accesses and only
   ~39.79M were external/CXL accesses (hwhint_extmem_accesses).
   That extmem count matches pages promoted (39.70M) and
   pghot_recorded_accesses (39.79M) very closely: nearly every
   distinct external-memory access observed led to a promotion,
   i.e. precise hot-page targeting.

5. Negligible event loss. hwhint_dropped_events = 6,147 out of
   ~554M total (~0.001%), so the SPSC delivery path kept up with
   the hardware sample rate.

6. Migration is promotion-only. pgdemote_* and pgpromote_candidate
   are 0 across all runs; memory is pre-staged on node 2 and DRAM
   has ample headroom (~252 GiB/node vs ~161 GiB), so pages flow
   node 2 -> node 1 with no demotion pressure.

7. Caveats: Verification reported UNSUCCESSFUL in every run
   (consistent across all three, so a benchmark class/build
   artifact rather than a tiering effect). These are single runs
   per config; the ~9% (C vs B) gap should be confirmed with
   repeats to establish variance.

Bottom line: the AMD IBS Memory Profiler source drives pghot
promotion purely from hardware access samples -- no NUMA hint
faults, no PTE scanning -- and recovers ~92% of kernel
NUMA-balancing tiering performance on NAS BT, at 2.15x over the
untiered baseline.

  parent reply	other threads:[~2026-09-24  6:32 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-24  6:22 Bharata B Rao
2026-09-24  6:22 ` [RFC PATCH v0 1/3] x86/ibs: Move IBS caps definitions into its own header Bharata B Rao
2026-09-24  6:22 ` [RFC PATCH v0 2/3] x86/mm/ibs: In-kernel driver for AMD IBS Memory Profiler Bharata B Rao
2026-09-24  6:22 ` [RFC PATCH v0 3/3] x86/mm/ibs: Add runtime controls for IBS memprofiler Bharata B Rao
2026-09-24  6:26 ` [RFC PATCH v0 0/3] pghot: x86: IBS Memory Profiler for hot page promotion Bharata B Rao
2026-09-24  6:27 ` Bharata B Rao
2026-09-24  6:31 ` Bharata B Rao [this message]
2026-09-24  6:33 ` Bharata B Rao
2026-09-24  6:35 ` Bharata B Rao
2026-09-24  6:37 ` Bharata B Rao

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=1928da1c-e07e-4523-98b6-611b62a53143@amd.com \
    --to=bharata@amd.com \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=akpm@linux-foundation.org \
    --cc=balbirs@nvidia.com \
    --cc=bp@alien8.de \
    --cc=byungchul@sk.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=dave@stgolabs.net \
    --cc=david@kernel.org \
    --cc=donettom@linux.ibm.com \
    --cc=gourry@gourry.net \
    --cc=hpa@zytor.com \
    --cc=joshua.hahnjy@gmail.com \
    --cc=kinseyho@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linyongting@bytedance.com \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --cc=nifan.cxl@gmail.com \
    --cc=peterz@infradead.org \
    --cc=rientjes@google.com \
    --cc=shivankg@amd.com \
    --cc=sj@kernel.org \
    --cc=tglx@kernel.org \
    --cc=weixugc@google.com \
    --cc=willy@infradead.org \
    --cc=x86@kernel.org \
    --cc=xin@zytor.com \
    --cc=xuezhengchu@huawei.com \
    --cc=yiannis@zptcorp.com \
    --cc=ying.huang@linux.alibaba.com \
    --cc=yuanchu@google.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

all inboxes | Powered by JetHome®