Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1442548 > unrolled thread

Re: [PATCH 2/4] x86, pagetable: ignore A/D bits in pte/pmd/pud_none()

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 2/4] x86, pagetable: ignore A/D bits in pte/pmd/pud_none() Michal Hocko <mhocko@kernel.org> - 2016-07-13 17:30 +0200
    Re: [PATCH 2/4] x86, pagetable: ignore A/D bits in pte/pmd/pud_none() Dave Hansen <dave@sr71.net> - 2016-07-13 17:50 +0200
      Re: [PATCH 2/4] x86, pagetable: ignore A/D bits in pte/pmd/pud_none() Michal Hocko <mhocko@kernel.org> - 2016-07-14 08:20 +0200

#1442548 — Re: [PATCH 2/4] x86, pagetable: ignore A/D bits in pte/pmd/pud_none()

On Thu 07-07-16 17:19:12, Dave Hansen wrote:
> 
> From: Dave Hansen <dave.hansen@linux.intel.com>
> 
> The erratum we are fixing here can lead to stray setting of the
> A and D bits.  That means that a pte that we cleared might
> suddenly have A/D set.  So, stop considering those bits when
> determining if a pte is pte_none().  The same goes for the
> other pmd_none() and pud_none().  pgd_none() can be skipped
> because it is not affected; we do not use PGD entries for
> anything other than pagetables on affected configurations.
> 
> This adds a tiny amount of overhead to all pte_none() checks.
> I doubt we'll be able to measure it anywhere.

It would be better to introduce the overhead only for the affected
cpu models but I guess this is also acceptable. Would it be too
complicated to use alternatives for that?

> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>

Anyway
Acked-by: Michal Hocko <mhocko@suse.com>
> ---
> 
>  b/arch/x86/include/asm/pgtable.h       |   13 ++++++++++---
>  b/arch/x86/include/asm/pgtable_types.h |    6 ++++++
>  2 files changed, 16 insertions(+), 3 deletions(-)
> 
> diff -puN arch/x86/include/asm/pgtable.h~knl-strays-20-mod-pte-none arch/x86/include/asm/pgtable.h
> --- a/arch/x86/include/asm/pgtable.h~knl-strays-20-mod-pte-none	2016-07-07 17:17:43.974764976 -0700
> +++ b/arch/x86/include/asm/pgtable.h	2016-07-07 17:17:43.980765246 -0700
> @@ -480,7 +480,7 @@ pte_t *populate_extra_pte(unsigned long
>  
>  static inline int pte_none(pte_t pte)
>  {
> -	return !pte.pte;
> +	return !(pte.pte & ~(_PAGE_KNL_ERRATUM_MASK));
>  }
>  
>  #define __HAVE_ARCH_PTE_SAME
> @@ -552,7 +552,8 @@ static inline int pmd_none(pmd_t pmd)
>  {
>  	/* Only check low word on 32-bit platforms, since it might be
>  	   out of sync with upper half. */
> -	return (unsigned long)native_pmd_val(pmd) == 0;
> +	unsigned long val = native_pmd_val(pmd);
> +	return (val & ~_PAGE_KNL_ERRATUM_MASK) == 0;
>  }
>  
>  static inline unsigned long pmd_page_vaddr(pmd_t pmd)
> @@ -616,7 +617,7 @@ static inline unsigned long pages_to_mb(
>  #if CONFIG_PGTABLE_LEVELS > 2
>  static inline int pud_none(pud_t pud)
>  {
> -	return native_pud_val(pud) == 0;
> +	return (native_pud_val(pud) & ~(_PAGE_KNL_ERRATUM_MASK)) == 0;
>  }
>  
>  static inline int pud_present(pud_t pud)
> @@ -694,6 +695,12 @@ static inline int pgd_bad(pgd_t pgd)
>  
>  static inline int pgd_none(pgd_t pgd)
>  {
> +	/*
> +	 * There is no need to do a workaround for the KNL stray
> +	 * A/D bit erratum here.  PGDs only point to page tables
> +	 * except on 32-bit non-PAE which is not supported on
> +	 * KNL.
> +	 */
>  	return !native_pgd_val(pgd);
>  }
>  #endif	/* CONFIG_PGTABLE_LEVELS > 3 */
> diff -puN arch/x86/include/asm/pgtable_types.h~knl-strays-20-mod-pte-none arch/x86/include/asm/pgtable_types.h
> --- a/arch/x86/include/asm/pgtable_types.h~knl-strays-20-mod-pte-none	2016-07-07 17:17:43.976765066 -0700
> +++ b/arch/x86/include/asm/pgtable_types.h	2016-07-07 17:17:43.980765246 -0700
> @@ -70,6 +70,12 @@
>  			 _PAGE_PKEY_BIT2 | \
>  			 _PAGE_PKEY_BIT3)
>  
> +#if defined(CONFIG_X86_64) || defined(CONFIG_X86_PAE)
> +#define _PAGE_KNL_ERRATUM_MASK (_PAGE_DIRTY | _PAGE_ACCESSED)
> +#else
> +#define _PAGE_KNL_ERRATUM_MASK 0
> +#endif
> +
>  #ifdef CONFIG_KMEMCHECK
>  #define _PAGE_HIDDEN	(_AT(pteval_t, 1) << _PAGE_BIT_HIDDEN)
>  #else
> _

-- 
Michal Hocko
SUSE Labs

[toc] | [next] | [standalone]

#1442564

On 07/13/2016 08:21 AM, Michal Hocko wrote:
>> > This adds a tiny amount of overhead to all pte_none() checks.
>> > I doubt we'll be able to measure it anywhere.
> It would be better to introduce the overhead only for the affected
> cpu models but I guess this is also acceptable. Would it be too
> complicated to use alternatives for that?

The patch as it stands ends up doing a one-instruction change in
pte_none().  It goes from

    64c8:       48 85 ff                test   %rdi,%rdi

to

    64a8:       48 f7 c7 9f ff ff ff    test   $0xffffffffffffff9f,%rdi

So it essentially eats 4 bytes of icache more than it did before.  But,
it's the same number of instructions, and I can't imagine that the CPU
will have any more trouble with a test against an immediate than a test
against 0.

We could theoretically do alternatives for this, but we would at *best*
end up with 4 bytes of noops.  So, unless the processor likes decoding 4
noops better than 4 bytes of immediate as part of an instruction, we'll
not win anything.  *Plus* the ugliness of the assembly that we'll need
to have the compiler guarantee that the PTE ends up in %rdi.

[toc] | [prev] | [next] | [standalone]

#1443089

On Wed 13-07-16 08:47:51, Dave Hansen wrote:
> On 07/13/2016 08:21 AM, Michal Hocko wrote:
> >> > This adds a tiny amount of overhead to all pte_none() checks.
> >> > I doubt we'll be able to measure it anywhere.
> > It would be better to introduce the overhead only for the affected
> > cpu models but I guess this is also acceptable. Would it be too
> > complicated to use alternatives for that?
> 
> The patch as it stands ends up doing a one-instruction change in
> pte_none().  It goes from
> 
>     64c8:       48 85 ff                test   %rdi,%rdi
> 
> to
> 
>     64a8:       48 f7 c7 9f ff ff ff    test   $0xffffffffffffff9f,%rdi
> 
> So it essentially eats 4 bytes of icache more than it did before.  But,
> it's the same number of instructions, and I can't imagine that the CPU
> will have any more trouble with a test against an immediate than a test
> against 0.

I see. Thanks for the clarification.

> We could theoretically do alternatives for this, but we would at *best*
> end up with 4 bytes of noops.  So, unless the processor likes decoding 4
> noops better than 4 bytes of immediate as part of an instruction, we'll
> not win anything.  *Plus* the ugliness of the assembly that we'll need
> to have the compiler guarantee that the PTE ends up in %rdi.

Agreed!
-- 
Michal Hocko
SUSE Labs

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web