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: Thu, 3 Sep 2020 17:56:32 +0100 [thread overview]
Message-ID: <20200903165631.GC31409@gaia> (raw)
In-Reply-To: <1597655984-15428-2-git-send-email-anshuman.khandual@arm.com>
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()).
> diff --git a/arch/arm64/include/asm/pgtable-prot.h b/arch/arm64/include/asm/pgtable-prot.h
> index 4d867c6446c4..28792fdd9627 100644
> --- a/arch/arm64/include/asm/pgtable-prot.h
> +++ b/arch/arm64/include/asm/pgtable-prot.h
> @@ -19,6 +19,13 @@
> #define PTE_DEVMAP (_AT(pteval_t, 1) << 57)
> #define PTE_PROT_NONE (_AT(pteval_t, 1) << 58) /* only when !PTE_VALID */
>
> +/*
> + * This help indicate that the entry is present i.e pmd_page()
Nit: add another . after i.e
> + * still points to a valid huge page in memory even if the pmd
> + * has been invalidated.
> + */
> +#define PMD_PRESENT_INVALID (_AT(pteval_t, 1) << 59) /* only when !PMD_SECT_VALID */
> +
> #ifndef __ASSEMBLY__
>
> #include <asm/cpufeature.h>
> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
> index d5d3fbe73953..7aa69cace784 100644
> --- a/arch/arm64/include/asm/pgtable.h
> +++ b/arch/arm64/include/asm/pgtable.h
> @@ -145,6 +145,18 @@ static inline pte_t set_pte_bit(pte_t pte, pgprot_t prot)
> return pte;
> }
>
> +static inline pmd_t clr_pmd_bit(pmd_t pmd, pgprot_t prot)
> +{
> + pmd_val(pmd) &= ~pgprot_val(prot);
> + return pmd;
> +}
Could you use clear_pmd_bit (instead of clr) for consistency with
clear_pte_bit()?
It would be good if the mm folk can do a sanity check on the assumptions
about pmd_present/pmdp_invalidate/pmd_trans_huge.
The patch looks fine to me otherwise, feel free to add:
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
--
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: Thu, 3 Sep 2020 17:56:32 +0100 [thread overview]
Message-ID: <20200903165631.GC31409@gaia> (raw)
In-Reply-To: <1597655984-15428-2-git-send-email-anshuman.khandual@arm.com>
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()).
> diff --git a/arch/arm64/include/asm/pgtable-prot.h b/arch/arm64/include/asm/pgtable-prot.h
> index 4d867c6446c4..28792fdd9627 100644
> --- a/arch/arm64/include/asm/pgtable-prot.h
> +++ b/arch/arm64/include/asm/pgtable-prot.h
> @@ -19,6 +19,13 @@
> #define PTE_DEVMAP (_AT(pteval_t, 1) << 57)
> #define PTE_PROT_NONE (_AT(pteval_t, 1) << 58) /* only when !PTE_VALID */
>
> +/*
> + * This help indicate that the entry is present i.e pmd_page()
Nit: add another . after i.e
> + * still points to a valid huge page in memory even if the pmd
> + * has been invalidated.
> + */
> +#define PMD_PRESENT_INVALID (_AT(pteval_t, 1) << 59) /* only when !PMD_SECT_VALID */
> +
> #ifndef __ASSEMBLY__
>
> #include <asm/cpufeature.h>
> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
> index d5d3fbe73953..7aa69cace784 100644
> --- a/arch/arm64/include/asm/pgtable.h
> +++ b/arch/arm64/include/asm/pgtable.h
> @@ -145,6 +145,18 @@ static inline pte_t set_pte_bit(pte_t pte, pgprot_t prot)
> return pte;
> }
>
> +static inline pmd_t clr_pmd_bit(pmd_t pmd, pgprot_t prot)
> +{
> + pmd_val(pmd) &= ~pgprot_val(prot);
> + return pmd;
> +}
Could you use clear_pmd_bit (instead of clr) for consistency with
clear_pte_bit()?
It would be good if the mm folk can do a sanity check on the assumptions
about pmd_present/pmdp_invalidate/pmd_trans_huge.
The patch looks fine to me otherwise, feel free to add:
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
--
Catalin
next prev parent reply other threads:[~2020-09-03 16:58 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 [this message]
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
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=20200903165631.GC31409@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.