All of lore.kernel.org
 help / color / mirror / Atom feed
From: Catalin Marinas <catalin.marinas@arm.com>
To: Ryan Roberts <ryan.roberts@arm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Mark Rutland <mark.rutland@arm.com>,
	John Hubbard <jhubbard@nvidia.com>,
	linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org
Subject: Re: [PATCH 2/2] arm64/mm: Improve comment in contpte_ptep_get_lockless()
Date: Mon, 4 Mar 2024 17:37:40 +0000	[thread overview]
Message-ID: <ZeYG5E9CDp9echBF@arm.com> (raw)
In-Reply-To: <089f689d-f8dd-48ba-b6b0-6f91aa3b86f1@arm.com>

On Mon, Mar 04, 2024 at 12:54:23PM +0000, Ryan Roberts wrote:
> On 01/03/2024 18:47, Catalin Marinas wrote:
> > On Mon, Feb 26, 2024 at 12:03:21PM +0000, Ryan Roberts wrote:
> >> Make clear the atmicity/consistency requirements of the API and how we
> >> achieve them.
> >>
> >> Link: https://lore.kernel.org/linux-mm/Zc-Tqqfksho3BHmU@arm.com/
> >> Signed-off-by: Ryan Roberts <ryan.roberts@arm.com>
> >> ---
> >>  arch/arm64/mm/contpte.c | 24 ++++++++++++++----------
> >>  1 file changed, 14 insertions(+), 10 deletions(-)
[...]
> > Throughout the callers of this function, I couldn't find one where it
> > matters. So I concluded that they don't need the dirty state. Normally
> > the dirty state is passed to the page flags, so not lost after the pte
> > has been cleaned.
> 
> I agree we can simplify the semantics. But I think its better done in a separate
> series (which I previously linked).
> 
> What's the bottom line here? Are you ok with this comment as a short term
> solution for now, or do you want something more radical (i.e. push to get the
> series that does these simplifications reviewed and in time for v6.9).
> 
> I still believe the current ptep_get_lockless() implementation is correct. So
> given I have a plan to simplify in the long run, I hope we can still get this
> series into v6.9 as planned.

Yes, I'm fine with this patch. Assuming Andrew picked them up:

Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>

I'd like to get the simplification in as well at some point as I think
our ptep_get_lockless() is unnecessarily complex for most use-cases.

-- 
Catalin

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Catalin Marinas <catalin.marinas@arm.com>
To: Ryan Roberts <ryan.roberts@arm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Mark Rutland <mark.rutland@arm.com>,
	John Hubbard <jhubbard@nvidia.com>,
	linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org
Subject: Re: [PATCH 2/2] arm64/mm: Improve comment in contpte_ptep_get_lockless()
Date: Mon, 4 Mar 2024 17:37:40 +0000	[thread overview]
Message-ID: <ZeYG5E9CDp9echBF@arm.com> (raw)
In-Reply-To: <089f689d-f8dd-48ba-b6b0-6f91aa3b86f1@arm.com>

On Mon, Mar 04, 2024 at 12:54:23PM +0000, Ryan Roberts wrote:
> On 01/03/2024 18:47, Catalin Marinas wrote:
> > On Mon, Feb 26, 2024 at 12:03:21PM +0000, Ryan Roberts wrote:
> >> Make clear the atmicity/consistency requirements of the API and how we
> >> achieve them.
> >>
> >> Link: https://lore.kernel.org/linux-mm/Zc-Tqqfksho3BHmU@arm.com/
> >> Signed-off-by: Ryan Roberts <ryan.roberts@arm.com>
> >> ---
> >>  arch/arm64/mm/contpte.c | 24 ++++++++++++++----------
> >>  1 file changed, 14 insertions(+), 10 deletions(-)
[...]
> > Throughout the callers of this function, I couldn't find one where it
> > matters. So I concluded that they don't need the dirty state. Normally
> > the dirty state is passed to the page flags, so not lost after the pte
> > has been cleaned.
> 
> I agree we can simplify the semantics. But I think its better done in a separate
> series (which I previously linked).
> 
> What's the bottom line here? Are you ok with this comment as a short term
> solution for now, or do you want something more radical (i.e. push to get the
> series that does these simplifications reviewed and in time for v6.9).
> 
> I still believe the current ptep_get_lockless() implementation is correct. So
> given I have a plan to simplify in the long run, I hope we can still get this
> series into v6.9 as planned.

Yes, I'm fine with this patch. Assuming Andrew picked them up:

Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>

I'd like to get the simplification in as well at some point as I think
our ptep_get_lockless() is unnecessarily complex for most use-cases.

-- 
Catalin


  reply	other threads:[~2024-03-04 17:37 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-26 12:03 [PATCH 0/2] Address some contpte nits Ryan Roberts
2024-02-26 12:03 ` Ryan Roberts
2024-02-26 12:03 ` [PATCH 1/2] arm64/mm: Export contpte symbols only to GPL users Ryan Roberts
2024-02-26 12:03   ` Ryan Roberts
2024-02-26 12:25   ` David Hildenbrand
2024-02-26 12:25     ` David Hildenbrand
2024-02-26 12:40     ` Ryan Roberts
2024-02-26 12:40       ` Ryan Roberts
2024-02-27  2:49   ` John Hubbard
2024-02-27  2:49     ` John Hubbard
2024-03-04 17:38   ` Catalin Marinas
2024-03-04 17:38     ` Catalin Marinas
2024-02-26 12:03 ` [PATCH 2/2] arm64/mm: Improve comment in contpte_ptep_get_lockless() Ryan Roberts
2024-02-26 12:03   ` Ryan Roberts
2024-02-26 12:30   ` David Hildenbrand
2024-02-26 12:30     ` David Hildenbrand
2024-02-26 12:37     ` Ryan Roberts
2024-02-26 12:37       ` Ryan Roberts
2024-02-26 12:40       ` David Hildenbrand
2024-02-26 12:40         ` David Hildenbrand
2024-02-27 23:45   ` John Hubbard
2024-02-27 23:45     ` John Hubbard
2024-03-01 18:47   ` Catalin Marinas
2024-03-01 18:47     ` Catalin Marinas
2024-03-04 12:54     ` Ryan Roberts
2024-03-04 12:54       ` Ryan Roberts
2024-03-04 17:37       ` Catalin Marinas [this message]
2024-03-04 17:37         ` Catalin Marinas
2024-03-04 18:40         ` Ryan Roberts
2024-03-04 18:40           ` Ryan Roberts
2024-03-04 22:04           ` David Hildenbrand
2024-03-04 22:04             ` David Hildenbrand
2024-03-05  9:13             ` Ryan Roberts
2024-03-05  9:13               ` Ryan Roberts
2024-03-05  9:14             ` Ryan Roberts
2024-03-05  9:14               ` Ryan Roberts

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=ZeYG5E9CDp9echBF@arm.com \
    --to=catalin.marinas@arm.com \
    --cc=akpm@linux-foundation.org \
    --cc=jhubbard@nvidia.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-mm@kvack.org \
    --cc=mark.rutland@arm.com \
    --cc=ryan.roberts@arm.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.