Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp5623710imm; Wed, 12 Sep 2018 08:40:07 -0700 (PDT) X-Google-Smtp-Source: ANB0VdZt6HWKUBJHkrp8vaKhck95AvfG57NQ0msHLB4D+/OOuRN3ln4XlT2rv+ilkybK0fFERwar X-Received: by 2002:a17:902:286a:: with SMTP id e97-v6mr2956273plb.340.1536766807255; Wed, 12 Sep 2018 08:40:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536766807; cv=none; d=google.com; s=arc-20160816; b=wLM8GtQ7Q/7Qw4cjUNu7mCeR9T4myCCjY76ljQuczVkhAYe08MiCHI3p7OiUR91TLs ylq1BwWJ92zVfepa+B2v4VFaUK3O5LYke5jvB+To4RRj+G5IVheXXaE7+pGltu11YVAK 1QBq1JPmtz2a4YM3K0vt1cXV3OHZtxCcuETNXJhEOLMxA8E/CkskdMYz1XNa+8wYJSos wteLrj62CK1QvZk0X7n0XCR7wEqBQnSsz8alXw3ebENeQLF/cdrGk/eNiDbLnj282POA zXdI0mXcinnkxtHIUJgJgX+pNELEHszm+JlEhthAmsB7gTp+aHINnKzUYAwrWIzqq3Ji z0pg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:message-id :in-reply-to:date:references:subject:cc:to:from:dkim-signature; bh=MGE2jG+SWSZNqpEp28E7CyH1XABB1gKLFcOI3ByH3wE=; b=Jqf5HaA+Ecve47ZHkkaZl30VDTjgBe6zjysCQGWtAd19oS9OqTuycqILdPwGi8QZ5L B4myMrYgZlc+ftrdg10XaJ4SEwDvGWGxUrr7fiG7+FmaBkxaG09G6S8Gzd+2gpBfzVcf X5DQriP9ak4MFL+bH2uGEYQIJIxyYPKJ3HeVfoSosX29xawsE1VK5xzMIfogVC+bEkc9 WYOLGmzfOEsCbZQmqkBhp5eMC23SXU3XrEDWKLrxyEaYXFpKbfuU7SteotE7xBgRDtcm 9ZTS9Mu8RjpipY8ygKN/yTHE95W0EkGE+mMDFMzedaTKAJ/PEhz6rajG3TAb8Ml4dE2Q M8fQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@amazon.de header.s=amazon201209 header.b=pft6uJHq; 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; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=amazon.de Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x5-v6si1218004plv.304.2018.09.12.08.39.52; Wed, 12 Sep 2018 08:40:07 -0700 (PDT) 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; dkim=pass header.i=@amazon.de header.s=amazon201209 header.b=pft6uJHq; 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; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=amazon.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727391AbeILUnC (ORCPT + 99 others); Wed, 12 Sep 2018 16:43:02 -0400 Received: from smtp-fw-2101.amazon.com ([72.21.196.25]:4324 "EHLO smtp-fw-2101.amazon.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726640AbeILUnC (ORCPT ); Wed, 12 Sep 2018 16:43:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.de; i=@amazon.de; q=dns/txt; s=amazon201209; t=1536766679; x=1568302679; h=from:to:cc:subject:references:date:in-reply-to: message-id:mime-version; bh=MGE2jG+SWSZNqpEp28E7CyH1XABB1gKLFcOI3ByH3wE=; b=pft6uJHqVa1PlRpULOsQ7qUnT5oamLfAf03krZrah0qHdHoL/Srm7hNf JH75AIaLfkTzbk2FP+PtrxrU6kt7jpespH8bD+AMBkcJKbOx0sdjYEll3 nAKAg4tHp0xHsDL05oktNifo7JKE9yA0HWpqiBcdqrhVgwA0LuUvnuLZQ U=; X-IronPort-AV: E=Sophos;i="5.53,365,1531785600"; d="scan'208";a="697319287" Received: from iad6-co-svc-p1-lb1-vlan2.amazon.com (HELO email-inbound-relay-1d-f273de60.us-east-1.amazon.com) ([10.124.125.2]) by smtp-border-fw-out-2101.iad2.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Sep 2018 15:37:55 +0000 Received: from u54ee758033e858cfa736.ant.amazon.com (iad7-ws-svc-lb50-vlan2.amazon.com [10.0.93.210]) by email-inbound-relay-1d-f273de60.us-east-1.amazon.com (8.14.7/8.14.7) with ESMTP id w8CFbhM8018732 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Sep 2018 15:37:46 GMT Received: from u54ee758033e858cfa736.ant.amazon.com (localhost [127.0.0.1]) by u54ee758033e858cfa736.ant.amazon.com (8.15.2/8.15.2/Debian-3) with ESMTP id w8CFbgsx003922; Wed, 12 Sep 2018 17:37:42 +0200 Received: (from jsteckli@localhost) by u54ee758033e858cfa736.ant.amazon.com (8.15.2/8.15.2/Submit) id w8CFbdOh003914; Wed, 12 Sep 2018 17:37:39 +0200 X-Authentication-Warning: u54ee758033e858cfa736.ant.amazon.com: jsteckli set sender to jsteckli@amazon.de using -f From: Julian Stecklina To: Linus Torvalds Cc: David Woodhouse , Konrad Rzeszutek Wilk , juerg.haefliger@hpe.com, deepa.srinivasan@oracle.com, Jim Mattson , Andrew Cooper , Linux Kernel Mailing List , Boris Ostrovsky , linux-mm , Thomas Gleixner , joao.m.martins@oracle.com, pradeep.vincent@oracle.com, Andi Kleen , Khalid Aziz , kanth.ghatraju@oracle.com, Liran Alon , Kees Cook , Kernel Hardening , chris.hyser@oracle.com, Tyler Hicks , John Haxby , Jon Masters Subject: Re: Redoing eXclusive Page Frame Ownership (XPFO) with isolated CPUs in mind (for KVM to isolate its guests per CPU) References: Date: Wed, 12 Sep 2018 17:37:38 +0200 In-Reply-To: (Julian Stecklina's message of "Mon, 03 Sep 2018 16:51:35 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Julian Stecklina writes: > Linus Torvalds writes: > >> On Fri, Aug 31, 2018 at 12:45 AM Julian Stecklina wrote: >>> >>> I've been spending some cycles on the XPFO patch set this week. For the >>> patch set as it was posted for v4.13, the performance overhead of >>> compiling a Linux kernel is ~40% on x86_64[1]. The overhead comes almost >>> completely from TLB flushing. If we can live with stale TLB entries >>> allowing temporary access (which I think is reasonable), we can remove >>> all TLB flushing (on x86). This reduces the overhead to 2-3% for >>> kernel compile. >> >> I have to say, even 2-3% for a kernel compile sounds absolutely horrendous. > > Well, it's at least in a range where it doesn't look hopeless. > >> Kernel bullds are 90% user space at least for me, so a 2-3% slowdown >> from a kernel is not some small unnoticeable thing. > > The overhead seems to come from the hooks that XPFO adds to > alloc/free_pages. These hooks add a couple of atomic operations per > allocated (4K) page for book keeping. Some of these atomic ops are only > for debugging and could be removed. There is also some opportunity to > streamline the per-page space overhead of XPFO. I've updated my XPFO branch[1] to make some of the debugging optional and also integrated the XPFO bookkeeping with struct page, instead of requiring CONFIG_PAGE_EXTENSION, which removes some checks in the hot path. These changes push the overhead down to somewhere between 1.5 and 2% for my quad core box in kernel compile. This is close to the measurement noise, so I take suggestions for a better benchmark here. Of course, if you hit contention on the xpfo spinlock then performance will suffer. I guess this is what happened on Khalid's large box. I'll try to remove the spinlocks and add fixup code to the pagefault handler to see whether this improves the situation on large boxes. This might turn out to be ugly, though. Julian [1] http://git.infradead.org/users/jsteckli/linux-xpfo.git/shortlog/refs/heads/xpfo-master -- Amazon Development Center Germany GmbH Berlin - Dresden - Aachen main office: Krausenstr. 38, 10117 Berlin Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger Ust-ID: DE289237879 Eingetragen am Amtsgericht Charlottenburg HRB 149173 B