All of lore.kernel.org
 help / color / mirror / Atom feed
From: "David Hildenbrand (Arm)" <david@kernel.org>
To: Gregory Price <gourry@gourry.net>, linux-mm@kvack.org
Cc: linux-kernel@vger.kernel.org, kernel-team@meta.com,
	akpm@linux-foundation.org, ljs@kernel.org, liam@infradead.org,
	vbabka@kernel.org, rppt@kernel.org, surenb@google.com,
	mhocko@suse.com, mingo@redhat.com, peterz@infradead.org,
	juri.lelli@redhat.com, vincent.guittot@linaro.org,
	dietmar.eggemann@arm.com, rostedt@goodmis.org,
	bsegall@google.com, mgorman@suse.de, vschneid@redhat.com,
	kprateek.nayak@amd.com, ziy@nvidia.com,
	baolin.wang@linux.alibaba.com, nico.pache@linux.dev,
	ryan.roberts@arm.com, dev.jain@arm.com, baohua@kernel.org,
	lance.yang@linux.dev, usama.arif@linux.dev, kas@kernel.org,
	matthew.brost@intel.com, joshua.hahnjy@gmail.com,
	rakie.kim@sk.com, byungchul@sk.com, ying.huang@linux.alibaba.com,
	apopple@nvidia.com, jannh@google.com, pfalcato@suse.de,
	hannes@cmpxchg.org, shy828301@gmail.com, raghavendra.kt@amd.com,
	stable@vger.kernel.org
Subject: Re: [PATCH v3 1/7] mm: support promotion-only NUMA hinting scans
Date: Thu, 24 Sep 2026 13:45:24 +0200	[thread overview]
Message-ID: <8699eba1-21cd-420e-a992-51a90ba62b71@kernel.org> (raw)
In-Reply-To: <20260922182928.2199090-2-gourry@gourry.net>

On 9/22/26 20:29, Gregory Price wrote:
> From: "Gregory Price (Meta)" <gourry@gourry.net>
> 
> folio_can_map_prot_numa() derives folio eligibility from the global
> balancing mode. The mode (normal, tiering, or combined) describes
> which balancing mechanisms are enabled (placement vs promotion).
> 
> The global setting itself cannot describe the intent of an individual
> protection walk because normal-mode tempers its scanning activity based
> on a number of heuristics (read-only VMAs, activeness of VMA, etc).
> 
> In tiering or combined mode, applying these normal-mode optimizations
> to an entire VMA is incorrect and breaks tiering.
> 
>  - Opting VMAs out of scanning because they became inactive obviously
>    breaks tiering - because the intent is to identify when a VMA
>    becomes active.  Applying it in tiering modes causes

Incomplete sentence.

> 
>  - Opting Read-only file VMAs out of scanning is just incorrect for
>    tiering modes because its intent is to prevent bouncing between
>    sockets (east-west), while tiering controls tier migration
>    (north-south).  The result is hot read-only files can overload
>    lower tier bandwidth.
> 
> Add MM_CP_PROT_NUMA_PROMO_ONLY and let task_numa_work() select the type
> of walk. Build the change-protection flags there and pass them unchanged
> through change_prot_numa() so its PTE/PMD paths use the same decision.
> 
> Have folio_can_map_prot_numa() derive the single-threaded private state at
> the point of use instead of adding another precomputed boolean to the
> protection-walk interface. This keeps the interface focused on scan intent
> and avoids plumbing VMA-derived state beside cp_flags.
> 
> The tradeoff for the cleaner interface is an atomic mm_users read for each
> folio, rather than once per PTE range. Check the promotion-only top-tier
> exclusion bit first as a mild optimization.
> 
> The scan-intent interface is required by the following memory-tiering
> fixes and must accompany them when backported.
> 
> Fixes: c574bbe91703 ("NUMA balancing: optimize page placement for memory tiering system")
> Cc: stable@vger.kernel.org
> Suggested-by: David Hildenbrand <david@kernel.org>
> Link: https://lore.kernel.org/r/4d2853c9-edf4-4685-b186-7214ed6abd84@kernel.org
> Assisted-by: LLM
> Signed-off-by: Gregory Price (Meta) <gourry@gourry.net>
> ---

LGTM

Acked-by: David Hildenbrand (Arm) <david@kernel.org>

-- 
Cheers,

David


  reply	other threads:[~2026-09-24 11:45 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-22 18:29 [PATCH v3 0/7] sched/numa: stop VMA scan filters from gating promotion Gregory Price
2026-09-22 18:29 ` [PATCH v3 1/7] mm: support promotion-only NUMA hinting scans Gregory Price
2026-09-24 11:45   ` David Hildenbrand (Arm) [this message]
2026-09-24 14:08     ` Gregory Price
2026-09-22 18:29 ` [PATCH v3 2/7] mm: allow shared folios to be promoted to a fast tier Gregory Price
2026-09-24 11:59   ` David Hildenbrand (Arm)
2026-09-24 14:07     ` Gregory Price
2026-09-24 15:32       ` David Hildenbrand (Arm)
2026-09-24 15:37         ` Gregory Price
2026-09-24 15:42           ` Zi Yan
2026-09-22 18:29 ` [PATCH v3 3/7] sched/numa: scan read-only file mappings in tiering mode Gregory Price
2026-09-24 20:53   ` David Hildenbrand (Arm)
2026-09-25  0:35     ` Gregory Price
2026-09-25 10:04       ` David Hildenbrand (Arm)
2026-09-22 18:29 ` [PATCH v3 4/7] sched/numa: separate VMA placement from scan continuation Gregory Price
2026-09-25 10:53   ` David Hildenbrand (Arm)
2026-09-22 18:29 ` [PATCH v3 5/7] sched/numa: scan PID-inactive VMAs for promotion Gregory Price
2026-09-25 10:55   ` David Hildenbrand (Arm)
2026-09-22 18:29 ` [PATCH v3 6/7] mm: use BIT() for change_protection() flags Gregory Price
2026-09-24 20:38   ` David Hildenbrand (Arm)
2026-09-22 18:29 ` [PATCH v3 7/7] mm: use VMA flag helpers in NUMA balancing Gregory Price
2026-09-24 20:39   ` David Hildenbrand (Arm)

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=8699eba1-21cd-420e-a992-51a90ba62b71@kernel.org \
    --to=david@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=apopple@nvidia.com \
    --cc=baohua@kernel.org \
    --cc=baolin.wang@linux.alibaba.com \
    --cc=bsegall@google.com \
    --cc=byungchul@sk.com \
    --cc=dev.jain@arm.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=gourry@gourry.net \
    --cc=hannes@cmpxchg.org \
    --cc=jannh@google.com \
    --cc=joshua.hahnjy@gmail.com \
    --cc=juri.lelli@redhat.com \
    --cc=kas@kernel.org \
    --cc=kernel-team@meta.com \
    --cc=kprateek.nayak@amd.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=matthew.brost@intel.com \
    --cc=mgorman@suse.de \
    --cc=mhocko@suse.com \
    --cc=mingo@redhat.com \
    --cc=nico.pache@linux.dev \
    --cc=peterz@infradead.org \
    --cc=pfalcato@suse.de \
    --cc=raghavendra.kt@amd.com \
    --cc=rakie.kim@sk.com \
    --cc=rostedt@goodmis.org \
    --cc=rppt@kernel.org \
    --cc=ryan.roberts@arm.com \
    --cc=shy828301@gmail.com \
    --cc=stable@vger.kernel.org \
    --cc=surenb@google.com \
    --cc=usama.arif@linux.dev \
    --cc=vbabka@kernel.org \
    --cc=vincent.guittot@linaro.org \
    --cc=vschneid@redhat.com \
    --cc=ying.huang@linux.alibaba.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.