Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp736031imu; Fri, 7 Dec 2018 08:08:48 -0800 (PST) X-Google-Smtp-Source: AFSGD/UycpdX0fxzo5fPBycPD9xZ9awJV5797toTnheYmkY3G+5LKJbrvarq0vsxBe9w1RlCE1Ra X-Received: by 2002:a62:c42:: with SMTP id u63mr2748724pfi.73.1544198928269; Fri, 07 Dec 2018 08:08:48 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1544198928; cv=none; d=google.com; s=arc-20160816; b=cdy6XUDYCdAVBCfjcNd4PBuQ9kLrF9Kfe4CfJEZxigC9MBitX0dijEBm26NNqa7L5X RJaxafC7iNKYlfF6yd/iuhRmoyEppWOfWP2q4cxicfGZu7mPUExKDr4n2eDL2vum7Lh/ XpUzUm6QifWXAa+ukq2AIHs/xQjHJGF2cIAi+f3WCdR0uEf3OtEl0xDOLtUgRTMyXR5J xK7nW73KPHH5RARdlkK1mTIzsCCtEjOWfjnpFGo7OtYWsaA3cVSU4WYd8UDy+rQgAyz8 EjD8QkwmcyO72DRTmYsBxSQ/Vh7+xglPrCB2LFvMOLQrwpPqDb4L7Tj+Rm0J1ny2IvL9 6sPw== 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 :content-language:in-reply-to:mime-version:user-agent:date :message-id:cc:references:to:subject:from; bh=jU5PFSavYnC/2iHrjuy9OJKk+wa41lriwZfcESUOPHk=; b=Tm/IXDM02AaJwXG7QkfgnHdDjcV2vYuLF5ZBKRjfEL2YucapgzUrg8/ZRmKRAfmzYV RvRtsCOS0Pe0dMyq7WaFp08p+O+bQaPYkLssLRPsPmRityCnNR/J6UieXKfB8QIY9J0O EB0K/QSN4sw+IuWf5YnZdFgDSrrCMry1y3IZ6akwzfafjVwtyzRqv9gVn7wMxIsik3dm GwiGQSjnVfYeVBVjDe/cwQwrNmu920126JJUD78B30ywe3JK7CYCnTMMkzksdM0uB/OR eqWBo/NDAYwJpe9Ou9aRDbMkf90UDJGD+kxNgIR+6sB6rtR+I7UDln6NerhtCW5csPbD Pmmg== 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 q18si3107104pls.30.2018.12.07.08.08.19; Fri, 07 Dec 2018 08:08:48 -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 S1726142AbeLGQGk (ORCPT + 99 others); Fri, 7 Dec 2018 11:06:40 -0500 Received: from dispatch1-us1.ppe-hosted.com ([148.163.129.52]:54126 "EHLO dispatch1-us1.ppe-hosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726065AbeLGQGj (ORCPT ); Fri, 7 Dec 2018 11:06:39 -0500 X-Virus-Scanned: Proofpoint Essentials engine Received: from webmail.solarflare.com (webmail.solarflare.com [12.187.104.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mx1-us3.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTPS id 414EFB40057; Fri, 7 Dec 2018 16:06:38 +0000 (UTC) Received: from ec-desktop.uk.solarflarecom.com (10.17.20.45) by ocex03.SolarFlarecom.com (10.20.40.36) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 7 Dec 2018 08:06:34 -0800 From: Edward Cree Subject: Re: [PATCH v2 0/4] Static calls To: Josh Poimboeuf References: CC: , , Paolo Abeni Message-ID: <0e96ac37-d5c5-86b6-833c-0de01ba18f0d@solarflare.com> Date: Fri, 7 Dec 2018 16:06:32 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Originating-IP: [10.17.20.45] X-TM-AS-Product-Ver: SMEX-12.5.0.1300-8.5.1010-24268.005 X-TM-AS-Result: No-4.672000-4.000000-10 X-TMASE-MatchedRID: VfovoVrt/oYDJrf2+hNOhVPjo7D4SFg47f6JAS2hKPjFJnEpmt9OE2WW d1VBI96H+QvemMQMGWw/D4CGpgn7NR+GMJJQ53gz3fn7n/ZHGqZ/aDoolm3GXUYvSDWdWaRhdnl a+4sEPupjq1QXe0nVE2/bkgMClkivkUIGI5Jp9O6PYUYzX2Xjl1AI6wCVrE3vYDnBmMnH0bAG42 yGukqJh7C1ePQuNeNe0RugigfesRTxoV3DFZL29RHRbGr1ECgHJPS3/6nvMcdDilB45O77xRk5K K4/zwVM94kvTNM1tWcH4jvnDtS/yk1+zyfzlN7ygxsfzkNRlfLdB/CxWTRRu+rAZ8KTspSzseDy ISflYBoMcOhAxODlIZcjbN19J10h+ZrTzn8+Y5ZbjM+MPZT/hDDB+c7h/UTREeTjIe2tHYdSqsz Zdd/QoLfcZeWoUNRpWswIoFcXV3ojZU2CAxYkI/guCCuaxGC9PA0H4ETs+eV+3BndfXUhXQ== X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--4.672000-4.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-24268.005 X-MDID: 1544198798-geKmvpATCBck Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Sorry if this has been pointed out before (it's a very long thread), but in the out-of-line implementation, it appears that static_call_update() never alters key->func. Am I right in thinking that this should be fixed by adding 'WRITE_ONCE(key->func, func);' just after the call to arch_static_call_transform() on line 159 of include/linux/static_call.h? Some background (why does key->func matter for the CONFIG_HAVE_STATIC_CALL_OUTLINE case?): I am experimenting with combining these static calls with the 'indirect call wrappers' notion that Paolo Abeni has been working on [1], using runtime instrumentation to determine a list of potential callees. (This allows us to cope with cases where the callees are in modules, or where different workloads may use different sets of callees for a given call site, neither of which is handled by Paolo's approach). The core of my design looks something like: static int dynamic_call_xyz(int (*func)(some_args), some_args) { if (func == dynamic_call_xyz_1.func) return static_call(dynamic_call_xyz_1, some_args); if (func == dynamic_call_xyz_2.func) return static_call(dynamic_call_xyz_2, some_args); return (*func)(some_args); } albeit with a bunch of extra (and currently rather ugly) stuff to collect the statistics needed to decide what to put in the static call keys, and mechanisms (RCU in my current case) to ensure that the static call isn't changed between checking its .func and actually calling it. -Ed PS: not on list, please keep me in CC. [1] https://lwn.net/Articles/773985/