Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp1739031imm; Mon, 3 Sep 2018 08:11:55 -0700 (PDT) X-Google-Smtp-Source: ANB0VdaRNBMkn7w1NmYVL9MRSRVuI5yrbIdn+tqkZTLMqAITqomlhfORtCQdAfkKffvdHhwTb1o4 X-Received: by 2002:a63:cc4f:: with SMTP id q15-v6mr26347605pgi.217.1535987513293; Mon, 03 Sep 2018 08:11:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1535987513; cv=none; d=google.com; s=arc-20160816; b=iq31JD9DNj4HvP8F3ahPTanxWpND2h3miYsjAZhd6MZylOyl1jbMgPVJGx7V7hhQE6 23N+N3ej+6VyrIrBh2rQPpgixi8S95b2HcJiIT5Ud0uqMXBAYe0vU5lBohKPjTbz9F0O ZOq+yz+HTKI0F6fIC2lPzN/zozSCuwgPBeKLzBO/uN/MHd4XEiyxUsvRKTC3eu44Y4FZ 7BfyM5nZF9/1mrohi/3g0iZ2SJJsHiJrQ0rLeo623vtnF0aF12jSuQh2iACHG/Gam09n Sqy3gw65W1Sw0zazOpdevKzt8pBYS/H6tGc2uAye1U0O7mTSTVJJv6GreuSEzb0TY3xv uU6w== 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 :arc-authentication-results; bh=aKtXfR4eyzdQOMWRmUCk7MtY2M+v43ba66ip7prFFTk=; b=DIVospb4VCsu3wm6m/6gui1ymffmcL9iZJWh+5EA9DSF3lmhq8w0CjmIcLnpblq0Yv teIQAis9mw+usiUlhHSOgXvucH+HS1K7upoAVFGnZa/1RkRUjLLI6E8JzHveZ81iUu9R WCgH71zMA/bCkPfO94c1UaU60AY2Gjy6kVgmbl+3E0rQTeVCelLMM/X2jfHKwCzVPK3S gyXVBQID7tKxcA9lqd+IPWsLjxZsYdw9w8pNXs1yN8cuzZ3dJBCBZ4e6hYI5Zy/i+59s HyfovbQgjkx238X2YV0l0+7XFqw3UizFGPq0/Zqes9YLHwSekI5a23tpXEuBfvt+/Otr Y+VQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@amazon.de header.s=amazon201209 header.b=l8F4Qhnt; 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 e22-v6si19208858pfb.185.2018.09.03.08.11.38; Mon, 03 Sep 2018 08:11:53 -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=l8F4Qhnt; 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 S1727455AbeICTai (ORCPT + 99 others); Mon, 3 Sep 2018 15:30:38 -0400 Received: from smtp-fw-9102.amazon.com ([207.171.184.29]:26995 "EHLO smtp-fw-9102.amazon.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725949AbeICTah (ORCPT ); Mon, 3 Sep 2018 15:30:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.de; i=@amazon.de; q=dns/txt; s=amazon201209; t=1535987401; x=1567523401; h=from:to:cc:subject:references:date:in-reply-to: message-id:mime-version; bh=aKtXfR4eyzdQOMWRmUCk7MtY2M+v43ba66ip7prFFTk=; b=l8F4Qhnt853ubh34gs5SFPe+NxAs4ieAS4ErQWEyLM8LsImTtwSMblza bKN43rZCwbSMTPzBETMBLLQox5J9VSYH5h7LYlz46MZibzgkj8IrHjEsz DRABPUEn6Vwt9kEEKVhpxtFyVgyOFIcU6Xgu/eOhgjo8Iuw8ICJURKnA0 c=; X-IronPort-AV: E=Sophos;i="5.53,325,1531785600"; d="scan'208";a="629135227" Received: from sea3-co-svc-lb6-vlan3.sea.amazon.com (HELO email-inbound-relay-2b-8cc5d68b.us-west-2.amazon.com) ([10.47.22.38]) by smtp-border-fw-out-9102.sea19.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Sep 2018 14:52:38 +0000 Received: from u54ee758033e858cfa736.ant.amazon.com (pdx2-ws-svc-lb17-vlan2.amazon.com [10.247.140.66]) by email-inbound-relay-2b-8cc5d68b.us-west-2.amazon.com (8.14.7/8.14.7) with ESMTP id w83Epjx4013981 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Sep 2018 14:51:48 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 w83EpfOs008659; Mon, 3 Sep 2018 16:51:41 +0200 Received: (from jsteckli@localhost) by u54ee758033e858cfa736.ant.amazon.com (8.15.2/8.15.2/Submit) id w83EpaSY008652; Mon, 3 Sep 2018 16:51:36 +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: Mon, 03 Sep 2018 16:51:35 +0200 In-Reply-To: (Linus Torvalds's message of "Sat, 1 Sep 2018 14:38:43 -0700") 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 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'll do some more in-depth profiling later this week. Julian 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