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: <Jonathan.Cameron@huawei.com>, <dave.hansen@intel.com>,
	<gourry@gourry.net>, <mgorman@techsingularity.net>,
	<mingo@redhat.com>, <peterz@infradead.org>,
	<raghavendra.kt@amd.com>, <riel@surriel.com>,
	<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>, <alok.rathore@samsung.com>,
	<shivankg@amd.com>, <donettom@linux.ibm.com>
Subject: Re: [PATCH v8 0/8] mm: Hot page tracking and promotion infrastructure - NAS BT
Date: Tue, 28 Jul 2026 11:29:31 +0530	[thread overview]
Message-ID: <64abacbb-e762-4705-8ba3-6b69572e2925@amd.com> (raw)
In-Reply-To: <20260728054356.291998-1-bharata@amd.com>

NAS Parallel Benchmark BT (Block Tri-diagonal solver), MPI version,
Class F modified, run with 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

While class D uses around 24G of memory (which is too less to show the
benefit of promition), class E results in around 368G of memory which
overflows my toptier. Hence I wanted something in between these classes.
So I have  modified class F to the problem size of 768 which results in
around 160GB of memory.

System is a 3-node tiered setup: node 0 and node 1 are DRAM (CPUs),
node 2 is a CPU-less CXL lower tier (~252 GiB per node). Before the
measurement phase all provisioned memory (~161.4 GiB across ranks)
is migrated to the lower-tier CXL node 2. The ranks are then resumed
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.

Legend (kernel / promotion source)
----------------------------------------------------------------------
  A = base-numab0       Base kernel, NO tiering (NUMAB=0); reference
  B = base-numab2       Base kernel, tiering via NUMA Balancing
                        mode 2 (hint-fault driven promotion)
  C = pghot-hintfaults  pghot kernel, hint-fault source (NUMAB=2)
  D = pghot-hwhints     pghot kernel, HW-hint source (IBS memory
                        profiler); does NOT need NUMA Balancing

Table 1a - Runtime (lower is better)
----------------------------------------------------------------------
Metric                          A          B          C          D
----------------------------------------------------------------------
NPB Time (s)              7482.25    3306.81    3313.82    3506.55
Speedup vs A (time)          1.00       2.26       2.26       2.13

Table 1b - Throughput (higher is better)
----------------------------------------------------------------------
Metric                          A          B          C          D
----------------------------------------------------------------------
NPB Mop/s total          52305.50  118350.48  118100.13  111608.96
Mop/s ratio vs A             1.00       2.26       2.26       2.13
Mop/s ratio vs B             0.44       1.00       1.00       0.94
Peak prov. mem (GiB)       161.38     161.38     161.38     161.38

Table 2 - vmstat counter deltas (after - before measurement window)
----------------------------------------------------------------------
Counter                             A         B         C         D
----------------------------------------------------------------------
pgpromote_success                   0  42180536  42169996  39898316
pgpromote_candidate                 0         0         0         0
pgpromote_candidate_nrl             0  42180536  42169996  39899553
pgdemote_kswapd                     0         0         0         0
pgdemote_direct                     0         0         0         0
numa_pte_updates                    0  42250308  45027035         0
numa_hint_faults                    0  42182545  44119239         0
numa_pages_migrated                 0  42182543  42169996  39898316
pgmigrate_success                   0  42182543  42169996  39898316
pghot_recorded_accesses             0         0  44119239  40004334
pghot_recorded_hintfaults           0         0  44119239         0
pghot_recorded_hwhints              0         0         0 584209652
hwhint_total_events                 0         0         0 584209975
hwhint_dram_accesses                0         0         0 544195074
hwhint_extmem_accesses              0         0         0  40005074
hwhint_useful_events                0         0         0 584209652

Key observations
----------------------------------------------------------------------
Bottom line: hint-fault pghot reproduces mainline NUMAB=2 exactly,
while HW-hint pghot delivers ~94% of that performance with zero
NUMA-balancing overhead - a good trade-off where IBS is available.

  parent reply	other threads:[~2026-07-28  5:59 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-28  5:43 [PATCH v8 0/8] mm: Hot page tracking and promotion infrastructure Bharata B Rao
2026-07-28  5:43 ` [PATCH v8 1/8] mm: migrate: Allow misplaced migration without VMA Bharata B Rao
2026-07-28  5:43 ` [PATCH v8 2/8] mm: migrate: Add promote_misplaced_memcg_folios() Bharata B Rao
2026-07-30  6:34   ` Bharata B Rao
2026-07-28  5:43 ` [PATCH v8 3/8] mm: Hot page tracking and promotion - pghot Bharata B Rao
2026-07-31 16:14   ` Bharata B Rao
2026-07-28  5:43 ` [PATCH v8 4/8] mm: pghot: Precision mode for pghot Bharata B Rao
2026-07-31 16:27   ` Bharata B Rao
2026-07-28  5:43 ` [PATCH v8 5/8] mm: sched: move NUMA balancing tiering promotion to pghot Bharata B Rao
2026-08-03  8:23   ` Bharata B Rao
2026-07-28  5:43 ` [PATCH v8 6/8] x86/ibs: Move IBS caps definitions into its own header Bharata B Rao
2026-07-28  5:43 ` [PATCH v8 7/8] x86/mm/ibs: In-kernel driver for AMD IBS Memory Profiler Bharata B Rao
2026-08-04  5:00   ` Bharata B Rao
2026-07-28  5:43 ` [PATCH v8 8/8] x86/mm/ibs: Add runtime controls for IBS memprofiler Bharata B Rao
2026-08-04  5:20   ` Bharata B Rao
2026-07-28  5:55 ` [PATCH v8 0/8] mm: Hot page tracking and promotion infrastructure - microbenchmark numbers Bharata B Rao
2026-07-28  5:59 ` Bharata B Rao [this message]
2026-07-28  6:02 ` [PATCH v8 0/8] mm: Hot page tracking and promotion infrastructure - Graph500 Bharata B Rao
2026-07-28  6:05 ` [PATCH v8 0/8] mm: Hot page tracking and promotion infrastructure - redis-memtier Bharata B Rao
2026-07-28  6:17 ` [PATCH v8 0/8] mm: Hot page tracking and promotion infrastructure - llama-bench Bharata B Rao
2026-07-28 18:14 ` [PATCH v8 0/8] mm: Hot page tracking and promotion infrastructure Andrew Morton
2026-07-28 18:24   ` Matthew Wilcox
2026-07-28 18:57     ` Gregory Price
2026-07-28 19:20       ` David Hildenbrand (Arm)
2026-07-28 19:59         ` Gregory Price
2026-07-29 11:45         ` Bharata B Rao
2026-08-10  3:38     ` Yongting Lin
2026-08-10  4:16       ` Matthew Wilcox
2026-07-29  9:35   ` Bharata B Rao
2026-07-29 13:54     ` SJ Park
2026-08-04  1:23       ` SJ Park
2026-08-06  5:49   ` Bharata B Rao
2026-08-06 13:44     ` SJ Park
2026-08-10  4:46       ` 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=64abacbb-e762-4705-8ba3-6b69572e2925@amd.com \
    --to=bharata@amd.com \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=akpm@linux-foundation.org \
    --cc=alok.rathore@samsung.com \
    --cc=balbirs@nvidia.com \
    --cc=byungchul@sk.com \
    --cc=dave.hansen@intel.com \
    --cc=dave@stgolabs.net \
    --cc=david@kernel.org \
    --cc=donettom@linux.ibm.com \
    --cc=gourry@gourry.net \
    --cc=joshua.hahnjy@gmail.com \
    --cc=kinseyho@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@techsingularity.net \
    --cc=mingo@redhat.com \
    --cc=nifan.cxl@gmail.com \
    --cc=peterz@infradead.org \
    --cc=raghavendra.kt@amd.com \
    --cc=riel@surriel.com \
    --cc=rientjes@google.com \
    --cc=shivankg@amd.com \
    --cc=sj@kernel.org \
    --cc=weixugc@google.com \
    --cc=willy@infradead.org \
    --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

Powered by JetHome