Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp1143113imu; Fri, 9 Nov 2018 11:38:15 -0800 (PST) X-Google-Smtp-Source: AJdET5c7d7g3an/7HTh7fA9dF7PO77anXWOhA21IiE1XudA2imd1vCPP0BuVkbyBYN/ZNfshLJH/ X-Received: by 2002:a17:902:8210:: with SMTP id x16-v6mr10240448pln.129.1541792295887; Fri, 09 Nov 2018 11:38:15 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1541792295; cv=none; d=google.com; s=arc-20160816; b=DYuntOn5pfx01rhXqrhLuCoe0mLqvqNIZBFc7Ty1bj8Ybxk1gLvbRrg2k3WxgHmRSQ Bo4Uoj4gJcp3sjooNlKwo80m4wc0so2HiQyCfup18orZqMUilMgIiyoZ7zZlXljmIE+4 Ed7aXbHXUPcfWyFOmiNhWYPXbGiiOoePb3fbp39dWkX6Jh+8qHCAIipDUxevW90DPt4B KU35d9vSDSFH1QglYLiRsYoUG1rBsOHWU8/fgU0zqIhL+u8BS6OUCTK5oCSRuFBsZgfc XSUSoJi3QK6z8uMDr+x4GZHVU97V1/U8cv5heXIw3bgI7ojOIfzx5U9QNYs/zobMGSxv je9g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=yFrMGrj9ac6CutMFtHLTy40WHnmjYXpjdMGsOL9tzXE=; b=xVViyPZG0jvCcZlrRISQakI520AAydCQhKp+PGgruNo5jl8imhJS1ApTpriZantSjJ aZ6gh2XeA0UiCip8pebv868a8IbxBqeLUKhfjBbcvoAp2MMNShRtToJU7bFkqk9FBT4j 0JWqOK5La06vHqc42/XBMY6r34Dfx8x/q9OaoFhlAZ9cxi486UuuY4Gm+B/R9HnWr2eJ zsko4k8AqcBsFUX9SdfoSRn0X39iBUxcYt3jtUaQtgQFQpzFALroZZ69U2MnSE1zb7cz RYD4XoCbUBHLJ8S8DPD3c6Awynz1bemMFc97lrdmtdrbQyYL7ahaWisT4EJxRvXq+82c cplA== 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 b131si7541131pga.51.2018.11.09.11.38.00; Fri, 09 Nov 2018 11:38:15 -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 S1727181AbeKJFTG (ORCPT + 99 others); Sat, 10 Nov 2018 00:19:06 -0500 Received: from mail.kernel.org ([198.145.29.99]:47346 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725758AbeKJFTG (ORCPT ); Sat, 10 Nov 2018 00:19:06 -0500 Received: from gandalf.local.home (cpe-66-24-56-78.stny.res.rr.com [66.24.56.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 9EA3C20855; Fri, 9 Nov 2018 19:37:04 +0000 (UTC) Date: Fri, 9 Nov 2018 14:37:03 -0500 From: Steven Rostedt To: Andy Lutomirski Cc: Josh Poimboeuf , Andy Lutomirski , Ingo Molnar , LKML , X86 ML , Ard Biesheuvel , Peter Zijlstra , Thomas Gleixner , Linus Torvalds , Masami Hiramatsu , Jason Baron , Jiri Kosina , David Laight , Borislav Petkov Subject: Re: [PATCH RFC 0/3] Static calls Message-ID: <20181109143703.5f2205bf@gandalf.local.home> In-Reply-To: <979DB163-EFBD-41BB-8481-155AAF526E72@amacapital.net> References: <20181109072811.GB86700@gmail.com> <20181109152139.zig45f6gp24btfbc@treble> <20181109164137.5cngbfrkm4ihj4ra@treble> <20181109134241.5f4ce3be@gandalf.local.home> <979DB163-EFBD-41BB-8481-155AAF526E72@amacapital.net> X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 9 Nov 2018 11:05:51 -0800 Andy Lutomirski wrote: > > Not sure what Andy was talking about, but I'm currently implementing > > tracepoints to use this, as tracepoints use indirect calls, and are a > > prime candidate for static calls, as I showed in my original RFC of > > this feature. > > > > > > Indeed. > > Although I had assumed that tracepoints already had appropriate jump label magic. It does. But that's not the problem I was trying to solve. It's that tracing took a 8% noise dive with retpolines when enabled (hackbench slowed down by 8% with all the trace events enabled compared to all trace events enabled without retpoline). That is, normal users (those not tracinng) are not affected by trace events slowing down by retpoline. Those that care about performance when they are tracing, are affected by retpoline, quite drastically. I'm doing another test run and measurements, to see how the unoptimized trampolines help, followed by the trampoline case. -- Steve