All of lore.kernel.org
 help / color / mirror / Atom feed
From: Catalin Marinas <catalin.marinas@arm.com>
To: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
	Suzuki Poulose <suzuki.poulose@arm.com>,
	Marc Zyngier <maz@kernel.org>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	akpm@linux-foundation.org, will@kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 1/2] arm64/mm: Change THP helpers to comply with generic MM semantics
Date: Tue, 8 Sep 2020 12:32:11 +0100	[thread overview]
Message-ID: <20200908113210.GC25591@gaia> (raw)
In-Reply-To: <b29e2bda-3299-e69f-90cf-1c9bd59a219d@arm.com>

On Tue, Sep 08, 2020 at 03:48:08PM +0530, Anshuman Khandual wrote:
> On 09/03/2020 10:26 PM, Catalin Marinas wrote:
> > On Mon, Aug 17, 2020 at 02:49:43PM +0530, Anshuman Khandual wrote:
> >> pmd_present() and pmd_trans_huge() are expected to behave in the following
> >> manner during various phases of a given PMD. It is derived from a previous
> >> detailed discussion on this topic [1] and present THP documentation [2].
> >>
> >> pmd_present(pmd):
> >>
> >> - Returns true if pmd refers to system RAM with a valid pmd_page(pmd)
> >> - Returns false if pmd does not refer to system RAM - Invalid pmd_page(pmd)
> > 
> > The second bullet doesn't make much sense. If you have a pmd mapping of
> > some I/O memory, pmd_present() still returns true (as does
> > pte_present()).
> 
> Derived this from an earlier discussion (https://lkml.org/lkml/2018/10/17/231)
> but current representation here might not be accurate.
> 
> Would this be any better ?
> 
> pmd_present(pmd):
> 
> - Returns true if pmd refers to system RAM with a valid pmd_page(pmd)
> - Returns false if pmd refers to a migration or swap entry

Yes, that's better

-- 
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: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org,
	will@kernel.org, akpm@linux-foundation.org,
	Mark Rutland <mark.rutland@arm.com>,
	Marc Zyngier <maz@kernel.org>,
	Suzuki Poulose <suzuki.poulose@arm.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] arm64/mm: Change THP helpers to comply with generic MM semantics
Date: Tue, 8 Sep 2020 12:32:11 +0100	[thread overview]
Message-ID: <20200908113210.GC25591@gaia> (raw)
In-Reply-To: <b29e2bda-3299-e69f-90cf-1c9bd59a219d@arm.com>

On Tue, Sep 08, 2020 at 03:48:08PM +0530, Anshuman Khandual wrote:
> On 09/03/2020 10:26 PM, Catalin Marinas wrote:
> > On Mon, Aug 17, 2020 at 02:49:43PM +0530, Anshuman Khandual wrote:
> >> pmd_present() and pmd_trans_huge() are expected to behave in the following
> >> manner during various phases of a given PMD. It is derived from a previous
> >> detailed discussion on this topic [1] and present THP documentation [2].
> >>
> >> pmd_present(pmd):
> >>
> >> - Returns true if pmd refers to system RAM with a valid pmd_page(pmd)
> >> - Returns false if pmd does not refer to system RAM - Invalid pmd_page(pmd)
> > 
> > The second bullet doesn't make much sense. If you have a pmd mapping of
> > some I/O memory, pmd_present() still returns true (as does
> > pte_present()).
> 
> Derived this from an earlier discussion (https://lkml.org/lkml/2018/10/17/231)
> but current representation here might not be accurate.
> 
> Would this be any better ?
> 
> pmd_present(pmd):
> 
> - Returns true if pmd refers to system RAM with a valid pmd_page(pmd)
> - Returns false if pmd refers to a migration or swap entry

Yes, that's better

-- 
Catalin


  reply	other threads:[~2020-09-08 11:33 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-17  9:19 [PATCH 0/2] arm64/mm: Enable THP migration Anshuman Khandual
2020-08-17  9:19 ` Anshuman Khandual
2020-08-17  9:19 ` [PATCH 1/2] arm64/mm: Change THP helpers to comply with generic MM semantics Anshuman Khandual
2020-08-17  9:19   ` Anshuman Khandual
2020-08-18  9:13   ` Jonathan Cameron
2020-08-18  9:13     ` Jonathan Cameron
2020-08-18  9:41     ` Anshuman Khandual
2020-08-18  9:41       ` Anshuman Khandual
2020-08-18 12:26       ` Jonathan Cameron
2020-08-18 12:26         ` Jonathan Cameron
2020-08-19  9:10         ` Anshuman Khandual
2020-08-19  9:10           ` Anshuman Khandual
2020-09-03 16:56   ` Catalin Marinas
2020-09-03 16:56     ` Catalin Marinas
2020-09-03 17:31     ` Ralph Campbell
2020-09-03 17:31       ` Ralph Campbell
2020-09-08 10:25       ` Anshuman Khandual
2020-09-08 10:25         ` Anshuman Khandual
2020-09-08 10:18     ` Anshuman Khandual
2020-09-08 10:18       ` Anshuman Khandual
2020-09-08 11:32       ` Catalin Marinas [this message]
2020-09-08 11:32         ` Catalin Marinas
2020-08-17  9:19 ` [PATCH 2/2] arm64/mm: Enable THP migration Anshuman Khandual
2020-08-17  9:19   ` Anshuman Khandual
2020-09-03 16:58   ` Catalin Marinas
2020-09-03 16:58     ` Catalin Marinas

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=20200908113210.GC25591@gaia \
    --to=catalin.marinas@arm.com \
    --cc=akpm@linux-foundation.org \
    --cc=anshuman.khandual@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mark.rutland@arm.com \
    --cc=maz@kernel.org \
    --cc=suzuki.poulose@arm.com \
    --cc=will@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 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.