Received: by 10.223.176.5 with SMTP id f5csp906566wra; Wed, 7 Feb 2018 09:23:21 -0800 (PST) X-Google-Smtp-Source: AH8x224tkfVIkVA1BIFuljLGYOUY74t7KmgoSUODc5VRsTtAMf9eZSk/mlvaT2czkn9VW4vS2nJ4 X-Received: by 2002:a17:902:74c9:: with SMTP id f9-v6mr6641089plt.89.1518024200920; Wed, 07 Feb 2018 09:23:20 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518024200; cv=none; d=google.com; s=arc-20160816; b=TVx11YHxixSv7nqGUZJpRwR1qPnQTdiLD7IlFxpdttTP89o2Ok9x98P087swaS+nr7 HS/BEBuVPViNvdKVHpi2+2R0CyQxJAHhTFh+mCAq4Kf6DFlm4yWWkPFAvF3e1N7bUvPv WlAOhIQvw5T0ZhKzvXonFAOTDLPNrSbkSq/d5QMrddtdyjfxAC8M+ZKbqht4f1lUraPh BSivOWjC/QdO3DIwx0RlzV1D8BR2Wb/r7LCTSQlS5pCB9enxLg9IIJCvqUtp3etpctXq Rn5EkTLGZ289fI1gIADFWt9xaGAZIzv/7hU8PabuIAtzVT++n5RGfEQv2AcY/QHSzZmW ONkA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:from:cc:to:subject :content-transfer-encoding:mime-version:references:in-reply-to :user-agent:date:arc-authentication-results; bh=89UDmXfJQZXQ9ziFvwV0LTWPVI9FX4seKs+HkLkYbPI=; b=M0JDoWzIbPDba963zJ6SVSo2BduhaAXBqvTBN2DN7wyViMyDzzTzF3lQOXp5FOafxH tvOEuRuZPIrd2whUv6xBJXYdax8PWttvBUtcGXbsuFWZP1+xF0AvU6hpgqZ3yLH6wapU 4+QaI3BnEMN402YAGKWcMnmS4L6GJE4zW6n4VP+8OldkfxO1dw/lObWqjtJ5A/3WjkEs 04uYI1o+/CBas912mAEAZavHMxOcL9KQ2Z9Kpo0wIGZLCXjW6HrS3V2upWtbrVW3bQzh J2rj0yi5wwGKCeESejhercnazqXqj3QYNS6xdPqyThbXQrTQo+d7AwKhNSDzQE2ikzF5 7sCw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y27si1376725pfi.382.2018.02.07.09.23.06; Wed, 07 Feb 2018 09:23:20 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754755AbeBGRV5 convert rfc822-to-8bit (ORCPT + 99 others); Wed, 7 Feb 2018 12:21:57 -0500 Received: from terminus.zytor.com ([65.50.211.136]:39117 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754231AbeBGRV4 (ORCPT ); Wed, 7 Feb 2018 12:21:56 -0500 Received: from [IPv6:2607:fb90:a6e1:9727:fb4b:b4ed:26eb:741c] ([172.58.35.181]) (authenticated bits=0) by mail.zytor.com (8.15.2/8.15.2) with ESMTPSA id w17HEDha017477 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 7 Feb 2018 09:14:13 -0800 Date: Wed, 07 Feb 2018 09:13:57 -0800 User-Agent: K-9 Mail for Android In-Reply-To: References: <20180207145913.2703-1-kirill.shutemov@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Subject: Re: [RFC 0/3] x86: Patchable constants To: Linus Torvalds , "Kirill A. Shutemov" CC: the arch/x86 maintainers , Tom Lendacky , Peter Zijlstra , Dave Hansen , Andy Lutomirski , Borislav Petkov , linux-mm , Linux Kernel Mailing List From: hpa@zytor.com Message-ID: <5D7DF367-BFEF-49C5-93DF-5C19D887752A@zytor.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On February 7, 2018 9:01:42 AM PST, Linus Torvalds wrote: >On Wed, Feb 7, 2018 at 6:59 AM, Kirill A. Shutemov > 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 >│ 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 >│ 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.