From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751495AbbBPUzc (ORCPT ); Mon, 16 Feb 2015 15:55:32 -0500 Received: from mail-pd0-f174.google.com ([209.85.192.174]:43119 "EHLO mail-pd0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750972AbbBPUzb (ORCPT ); Mon, 16 Feb 2015 15:55:31 -0500 Message-ID: <54E2593D.1040007@amacapital.net> Date: Mon, 16 Feb 2015 12:55:25 -0800 From: Andy Lutomirski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Ingo Molnar , Linus Torvalds CC: linux-kernel@vger.kernel.org, Andy Lutomirski , Peter Zijlstra , Thomas Gleixner , Arnaldo Carvalho de Melo , Andrew Morton Subject: Re: [GIT PULL] perf x86 updates for v3.20 References: <20150216074840.GA25445@gmail.com> In-Reply-To: <20150216074840.GA25445@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/15/2015 11:48 PM, Ingo Molnar wrote: > Linus, > > Please pull the latest perf-core-for-linus git tree from: > > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git perf-core-for-linus > > # HEAD: a66734297f78707ce39d756b656bfae861d53f62 perf/x86: Add /sys/devices/cpu/rdpmc=2 to allow rdpmc for all tasks [...] > The extra CR4 manipulation adds ~ <50ns to the context > switch cost between rdpmc-capable and rdpmc-non-capable > mms. That's about the best I could benchmark, too -- if it was more than about 50ns, I'm pretty sure I wouldn't seen a difference, but, as it stands, it seems to have been lost in the noise. Maybe I should find a better benchmark. In any event, this series is probably a mixed bag performance-wise. In the best base, there's a small extra cost in context switches, and, when switching PCE, there's a CR4 write. On SVM guests, the CR4 write will suck. To balance that out, I removed a CR4 read from VMX entry and from global TLB flushes. The former mostly fixes a performance regression from a security fix a few releases back, and the I expect that the latter will more than offset the added context switch overhead (especially on SVM guests, where even CR4 reads exit AFAIK). Anyway, I tried and failed to detect any difference at all. Context switch timing was very noisy for me. --Andy