All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Hansen <dave@sr71.net>
To: Michal Hocko <mhocko@kernel.org>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org, linux-mm@kvack.org,
	torvalds@linux-foundation.org, akpm@linux-foundation.org,
	bp@alien8.de, ak@linux.intel.com, dave.hansen@intel.com,
	dave.hansen@linux.intel.com
Subject: Re: [PATCH 2/4] x86, pagetable: ignore A/D bits in pte/pmd/pud_none()
Date: Wed, 13 Jul 2016 08:47:51 -0700	[thread overview]
Message-ID: <578662A7.3040409@sr71.net> (raw)
In-Reply-To: <20160713152145.GC20693@dhcp22.suse.cz>

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.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: Dave Hansen <dave@sr71.net>
To: Michal Hocko <mhocko@kernel.org>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org, linux-mm@kvack.org,
	torvalds@linux-foundation.org, akpm@linux-foundation.org,
	bp@alien8.de, ak@linux.intel.com, dave.hansen@intel.com,
	dave.hansen@linux.intel.com
Subject: Re: [PATCH 2/4] x86, pagetable: ignore A/D bits in pte/pmd/pud_none()
Date: Wed, 13 Jul 2016 08:47:51 -0700	[thread overview]
Message-ID: <578662A7.3040409@sr71.net> (raw)
In-Reply-To: <20160713152145.GC20693@dhcp22.suse.cz>

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.

  reply	other threads:[~2016-07-13 15:47 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-08  0:19 [PATCH 0/4] [RFC][v4] Workaround for Xeon Phi PTE A/D bits erratum Dave Hansen
2016-07-08  0:19 ` Dave Hansen
2016-07-08  0:19 ` [PATCH 1/4] x86, swap: move swap offset/type up in PTE to work around erratum Dave Hansen
2016-07-08  0:19   ` Dave Hansen
2016-07-13  8:03   ` [tip:x86/mm] x86/mm: Move " tip-bot for Dave Hansen
2016-07-13 15:19   ` [PATCH 1/4] x86, swap: move " Michal Hocko
2016-07-13 15:19     ` Michal Hocko
2016-07-08  0:19 ` [PATCH 2/4] x86, pagetable: ignore A/D bits in pte/pmd/pud_none() Dave Hansen
2016-07-08  0:19   ` Dave Hansen
2016-07-13  8:03   ` [tip:x86/mm] x86/mm: Ignore " tip-bot for Dave Hansen
2016-07-13 15:21   ` [PATCH 2/4] x86, pagetable: ignore " Michal Hocko
2016-07-13 15:21     ` Michal Hocko
2016-07-13 15:47     ` Dave Hansen [this message]
2016-07-13 15:47       ` Dave Hansen
2016-07-14  6:13       ` Michal Hocko
2016-07-14  6:13         ` Michal Hocko
2016-07-08  0:19 ` [PATCH 3/4] x86: disallow running with 32-bit PTEs to work around erratum Dave Hansen
2016-07-08  0:19   ` Dave Hansen
2016-07-13  8:04   ` [tip:x86/mm] x86/mm: Disallow " tip-bot for Dave Hansen
2016-07-08  0:19 ` [PATCH 4/4] x86: use pte_none() to test for empty PTE Dave Hansen
2016-07-08  0:19   ` Dave Hansen
2016-07-13  8:04   ` [tip:x86/mm] x86/mm: Use " tip-bot for Dave Hansen
2016-07-13 15:18   ` [PATCH 4/4] x86: use " Michal Hocko
2016-07-13 15:18     ` Michal Hocko
2016-07-13 15:23     ` Julia Lawall
2016-07-13 15:23       ` Julia Lawall
2016-07-13 15:49     ` Julia Lawall
2016-07-13 15:49       ` Julia Lawall
2016-07-13 16:28       ` Dave Hansen
2016-07-13 16:28         ` Dave Hansen
2016-07-14 13:47   ` Vlastimil Babka
2016-07-14 13:47     ` Vlastimil Babka
2016-07-14 14:24     ` Dave Hansen
2016-07-14 14:24       ` Dave Hansen
2016-07-14 14:50       ` David Vrabel
2016-07-14 14:50         ` David Vrabel
2016-07-13  9:54 ` [PATCH 0/4] [RFC][v4] Workaround for Xeon Phi PTE A/D bits erratum Vlastimil Babka
2016-07-13  9:54   ` Vlastimil Babka
  -- strict thread matches above, loose matches on Subject: below --
2016-07-01 17:46 Dave Hansen
2016-07-01 17:47 ` [PATCH 2/4] x86, pagetable: ignore A/D bits in pte/pmd/pud_none() Dave Hansen
2016-07-01 17:47   ` Dave Hansen

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=578662A7.3040409@sr71.net \
    --to=dave@sr71.net \
    --cc=ak@linux.intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=bp@alien8.de \
    --cc=dave.hansen@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=x86@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.