linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Alexander Gordeev <agordeev@linux.ibm.com>
To: "David Hildenbrand (Arm)" <david@kernel.org>
Cc: Kevin Brodsky <kevin.brodsky@arm.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Gerald Schaefer <gerald.schaefer@linux.ibm.com>,
	Heiko Carstens <hca@linux.ibm.com>,
	Christian Borntraeger <borntraeger@linux.ibm.com>,
	Vasily Gorbik <gor@linux.ibm.com>,
	linux-s390@vger.kernel.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 1/2] mm: make lazy MMU mode context-aware
Date: Mon, 13 Apr 2026 15:43:22 +0200	[thread overview]
Message-ID: <896b3d93-8e60-42e2-b8bb-d3d4e8c99927-agordeev@linux.ibm.com> (raw)
In-Reply-To: <665a19a0-47c2-404c-bd2b-482ab51b8f64@kernel.org>

On Tue, Mar 31, 2026 at 11:11:22PM +0200, David Hildenbrand (Arm) wrote:
> >>> + * lazy_mmu_mode_enable_pte() - Enable the lazy MMU mode with
> >>> parameters
> >>
> >> You have to be a lot clearer about implications. For example, what
> >> happens if we would bail out and not process all ptes? What are the
> >> exact semantics.
> > 
> > The only implication is "only this address/PTE range could be updated
> > and that range may span one page table at most".
> 
> Probably phrase it stronger. "No ptes outside of this range must be
> updated" etc.

That turns out to be bit more complicated. The below cases do not fit
such a strong requirement:

1. copy_pte_range() operates on two ranges: source and destination.
Though lazy_mmu_mode_enable_for_pte_range() applies to the source one,
updates to the destination are still happen while in tha lazy mode.
(Although the lazy mode is not actually needed for the destination
unattached MM).

2. move_ptes() also operates on a source and destination ranges, but
unlike copy_pte_range() the destination range is also attached to the
currently active task.

3. Though theoretical, nesting sections with interleaving calls to
lazy_mmu_mode_enable() and lazy_mmu_mode_enable_for_pte_range() make
it difficult to define (let alone to implement) which range is currently
active, if any.

All of these goes away if we switch from for_pte_range() to fast_pte_range()
semantics:

/**
 * lazy_mmu_mode_enable_fast_pte_range() - Enable the lazy MMU mode with fast updates.
 * @mm: Address space the ptes represent.
 * @addr: Address of the first pte.
 * @end: End address of the range.
 * @ptep: Page table pointer for the first entry.
 *
 * Enters a new lazy MMU mode section and allows fast updates for PTEs
 * within the specified range, while PTEs outside of the range are
 * updated in the normal way - as if lazy_mmu_mode_enable() was called;
 * if lazy MMU mode was not already enabled, enables it and calls
 * arch_enter_lazy_mmu_mode_fast_pte_range(); if the mode was already
 * enabled, the provided PTE range is ignored.
 *
 * The PTE range must belong to the provided memory space and must
 * not cross a page table boundary.
 *
 * There are no requirements on the order or range completeness of PTE updates.
 *
 * Must be paired with a call to lazy_mmu_mode_disable().
 *
 * Has no effect if called:
 * - while paused (see lazy_mmu_mode_pause())
 * - in interrupt context
 */

Thoughts?

Thanks!


  reply	other threads:[~2026-04-13 13:43 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-25  7:41 [RFC PATCH 0/2] s390/mm: Batch PTE updates in lazy MMU mode Alexander Gordeev
2026-03-25  7:41 ` [RFC PATCH 1/2] mm: make lazy MMU mode context-aware Alexander Gordeev
2026-03-25  9:55   ` David Hildenbrand (Arm)
2026-03-25 16:20     ` Alexander Gordeev
2026-03-25 16:37       ` Alexander Gordeev
2026-03-31 14:15       ` Kevin Brodsky
2026-04-11  9:31         ` Alexander Gordeev
2026-04-13 10:01           ` Kevin Brodsky
2026-03-31 21:11       ` David Hildenbrand (Arm)
2026-04-13 13:43         ` Alexander Gordeev [this message]
2026-03-25  7:41 ` [RFC PATCH 2/2] s390/mm: Batch PTE updates in lazy MMU mode Alexander Gordeev

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=896b3d93-8e60-42e2-b8bb-d3d4e8c99927-agordeev@linux.ibm.com \
    --to=agordeev@linux.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=borntraeger@linux.ibm.com \
    --cc=david@kernel.org \
    --cc=gerald.schaefer@linux.ibm.com \
    --cc=gor@linux.ibm.com \
    --cc=hca@linux.ibm.com \
    --cc=kevin.brodsky@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-s390@vger.kernel.org \
    /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