linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: hpa@zytor.com
To: Linus Torvalds <torvalds@linux-foundation.org>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Cc: the arch/x86 maintainers <x86@kernel.org>,
	Tom Lendacky <thomas.lendacky@amd.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Dave Hansen <dave.hansen@intel.com>,
	Andy Lutomirski <luto@kernel.org>, Borislav Petkov <bp@suse.de>,
	linux-mm <linux-mm@kvack.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [RFC 0/3] x86: Patchable constants
Date: Wed, 07 Feb 2018 09:13:57 -0800	[thread overview]
Message-ID: <5D7DF367-BFEF-49C5-93DF-5C19D887752A@zytor.com> (raw)
In-Reply-To: <CA+55aFxJO7kDNp6wRnU58Z6-sPbK1SqdzpgLBTAe54mdPjnd=g@mail.gmail.com>

On February 7, 2018 9:01:42 AM PST, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>On Wed, Feb 7, 2018 at 6:59 AM, Kirill A. Shutemov
><kirill.shutemov@linux.intel.com> wrote:
>> This patchset introduces concept of patchable constants: constant
>values
>> that can be adjusted at boot-time in response to system configuration
>or
>> user input (kernel command-line).
>>
>> Patchable constants can replace variables that never changes at
>runtime
>> (only at boot-time), but used in very hot path.
>
>So I actually wanted something very close to this, but I think your
>approach is much too simplistic.
>
>You force all constants into a register, which means that the
>resulting code is always going to be very far from non-optimal.
>
>You also force a big "movabsq" instruction, which really is huge, and
>almost never needed. Together with the "use a register", it just makes
>for big code.
>
>What I wanted was something that can take things like a shift by a
>variable that is set once, and turn it into a shift by a boot-time
>constant. Which means that you literally end up patching the 8-bit
>immediate in the shift instruction itself.
>
>In particular, was looking at the dcache hashing code, and (to quote
>an old email of mine), what I wanted was to simplify the run-time
>constant part of this:
>
>│ mov $0x20,%ecx
>│ sub 0xaf8bd5(%rip),%ecx # ffffffff81d34600 <d_hash_shift>
>│ mov 0x8(%rsi),%r9
>│ add %r14d,%eax
>│ imul $0x9e370001,%eax,%eax
>│ shr %cl,%eax
>
>and it was the expression "32-d_hash_shift" that is really a constant,
>and that sequence of
>
>│ mov $0x20,%ecx
>│ sub 0xaf8bd5(%rip),%ecx # ffffffff81d34600 <d_hash_shift>
>│ shr %cl,%eax
>
>should be just a single
>
>│ shr $CONSTANT,%eax
>
>at runtime.
>
>Look - much smaller code, and register %rcx isn't used at all. And no
>D$ miss on loading that constant (that is a constant depending on
>boot-time setup only).
>
>It's rather more complex, but it actually gives a much bigger win. The
>code itself will be much better, and smaller.
>
>The *infrastructure* for the code gets pretty hairy, though.
>
>The good news is that the patch already existed to at least _some_
>degree. Peter Anvin did it about 18 months ago.
>
>It was not really pursued all the way because it *is* a lot of extra
>complexity, and I think there was some other hold-up, but he did have
>skeleton code for the actual replacement.
>
>There was a thread on the x86 arch list with the subject line
>
>    Disgusting pseudo-self-modifying code idea: "variable constants"
>
>but I'm unable to actually find the patch. I know there was at least a
>vert early prototype.
>
>Adding hpa to the cc in the hope that he has some prototype code still
>laying around..
>
>                Linus

I am currently working on it much more comprehensive set of patches for extremely this. I am already much further ahead and support most operations.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

--
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>

  reply	other threads:[~2018-02-07 17:21 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-07 14:59 Kirill A. Shutemov
2018-02-07 14:59 ` [RFC 1/3] x86: Introduce patchable constants Kirill A. Shutemov
2018-02-07 14:59 ` [RFC 2/3] x86/mm/encrypt: Convert __PHYSICAL_MASK to patchable constant Kirill A. Shutemov
2018-02-07 14:59 ` [RFC 3/3] x86/mm/encrypt: Convert sme_me_mask " Kirill A. Shutemov
2018-02-07 16:25 ` [RFC 0/3] x86: Patchable constants Peter Zijlstra
2018-02-07 17:12   ` Kirill A. Shutemov
2018-02-07 17:01 ` Linus Torvalds
2018-02-07 17:13   ` hpa [this message]
2018-02-07 20:20   ` H. Peter Anvin
2018-02-07 20:43     ` H. Peter Anvin

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=5D7DF367-BFEF-49C5-93DF-5C19D887752A@zytor.com \
    --to=hpa@zytor.com \
    --cc=bp@suse.de \
    --cc=dave.hansen@intel.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=luto@kernel.org \
    --cc=peterz@infradead.org \
    --cc=thomas.lendacky@amd.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox