Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp2074949imu; Sat, 10 Nov 2018 07:15:34 -0800 (PST) X-Google-Smtp-Source: AJdET5cwyB0fDjU/X1COCz3KyIp1pKKg3qZMUoNDUOcdvcfNDECYymlvYMl1VnB6Yys2eKic8jAr X-Received: by 2002:a17:902:e081:: with SMTP id cb1-v6mr13029412plb.206.1541862934049; Sat, 10 Nov 2018 07:15:34 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1541862934; cv=none; d=google.com; s=arc-20160816; b=YDoc0i6TtZzfv2tH2wnRtEMP11hYU5vFvqlCyNJibpfufm//JDmz7rCPGYiMzlIXwW b27VkM9jgqXpGHKOHOA4rQkPJuySDPcaA4emV8AbZa68NaFUSH7pQBJEyUpliwWMWxw9 6lUOSbqVwgOehJ/5ggLikLWibouV4FvujGVptuki8xgbmhnf3Ns2nvinEnjTG+mYb/9I 60RoQeeQnsIYx8SvUs7Hfru/l3JCKvQpdbSZMu8d7dI2OJPeIzCDXa8N+0LT2/TBaDUr Mez13p1w4l4708WT62ctQeljqT23BLStoGkUHGhvLRhShS0Cxwotud4cnxdTM5Y2jc6J WZyQ== 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 :dkim-signature; bh=zvKTSbE3jmF5d56TlFbiZaRLjhGDWhGFwStxmKzk5H0=; b=wJT/wf4Ul72CcQVXl5yDislxdG6lpORzpYEe3F1zzE/drchRR8caE8ZG+bgQd/iM2G Gc0v5ZYXNWuqnu0wjVBGNakVXC588byxDSrXe4ZDyl8mwNOc1zdFowGfciwO6+numqWw Jwxjiz2V+3c0InY0EVaMYpnule+bPVec7ZpAABX2lIRAs11c99AcXCXZ2Hae5YZUDcBb 70DAGshhDgpla5tlX0EZ89JId5c/qtB8iqHHhCoODjVgZLoq3RygI1JmZVYl+xLt1Fs1 aU88Eb41CuwcqPn3INDhLdSZiUK4p7CE8Ro5TrZIkA3HPLpfGsUxOVT2HH5m1YNQk5pq MjNg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b="z/eIjTPV"; 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=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r22-v6si14573947pfr.18.2018.11.10.07.15.18; Sat, 10 Nov 2018 07:15:34 -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; dkim=pass header.i=@kernel.org header.s=default header.b="z/eIjTPV"; 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=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726534AbeKKA7B (ORCPT + 99 others); Sat, 10 Nov 2018 19:59:01 -0500 Received: from mail.kernel.org ([198.145.29.99]:55630 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726188AbeKKA7B (ORCPT ); Sat, 10 Nov 2018 19:59:01 -0500 Received: from devbox (NE2965lan1.rev.em-net.ne.jp [210.141.244.193]) (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 02FCE20684; Sat, 10 Nov 2018 15:13:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1541862821; bh=81qEAnYxUYmY4xkweT2ZaldeaIIY/0vm89kY3Iz6ryc=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=z/eIjTPVo2Cfh0n4Bq1gMlYAf08kN9p8Qvp9h4lU1yFFV5qPWQHRSoT7SkC3W8GNj bdnQGB1VQA9NaZUAOxrfq5m8S17dR3caKTBVUeqE8SZVScjcPgXTkeUOrASJGECBee GJVJsvnY1XoG3DbWYfW6CugNrYknUsdhPjPjJeYE= Date: Sun, 11 Nov 2018 00:13:36 +0900 From: Masami Hiramatsu To: Andy Lutomirski Cc: Steven Rostedt , 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: <20181111001336.a08bcc27faf69cbcaec9b597@kernel.org> 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: Sylpheed 3.5.1 (GTK+ 2.24.31; x86_64-redhat-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: > > > > On Nov 9, 2018, at 10:42 AM, Steven Rostedt wrote: > > > > On Fri, 9 Nov 2018 10:41:37 -0600 > > Josh Poimboeuf wrote: > > > >>> On Fri, Nov 09, 2018 at 09:21:39AM -0600, Josh Poimboeuf wrote: > >>>> On Fri, Nov 09, 2018 at 07:16:17AM -0800, Andy Lutomirski wrote: > >>>>> On Thu, Nov 8, 2018 at 11:28 PM Ingo Molnar wrote: > >>>>> > >>>>> > >>>>> All other usecases are bonus, but it would certainly be interesting to > >>>>> investigate the impact of using these APIs for tracing: that too is a > >>>>> feature enabled everywhere but utilized only by a small fraction of Linux > >>>>> users - so literally every single cycle or instruction saved or hot-path > >>>>> shortened is a major win. > >>>> > >>>> For tracing, we'd want static_call_set_to_nop() or something like that, right? > >>> > >>> Are we talking about tracepoints? Or ftrace? > >> > >> Since ftrace changes calls to nops, and vice versa, I assume you meant > >> ftrace. I don't think ftrace is a good candidate for this, as it's > >> inherently more flexible than this API would reasonably allow. > >> > > > > 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. As far as I know, the jump label magic is for reducing the overhead when the tracepoint is OFF (because it can skip function parameter preparation), and this static call will be good when the tracepoint is ON (enabled) because of this can avoid retpoline performance degradation. Thank you, -- Masami Hiramatsu