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.
next prev 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®