From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 122082 invoked by alias); 31 Oct 2018 21:22:25 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 122063 invoked by uid 89); 31 Oct 2018 21:22:24 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE,KAM_SHORT,SPF_HELO_PASS,SPF_PASS,UNPARSEABLE_RELAY autolearn=ham version=3.3.2 spammy=H*c:alternative X-HELO: userp2120.oracle.com Received: from userp2120.oracle.com (HELO userp2120.oracle.com) (156.151.31.85) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 31 Oct 2018 21:22:20 +0000 Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w9VLE8RA061011; Wed, 31 Oct 2018 21:22:18 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=corp-2018-07-02; bh=0Rcm+XkAKLGweEzafznNvBXcnBxjr2FysBYm4C1aX2M=; b=VJwW4HeHRvoUM7pFI4BrsCz0Txro1bc08Tr3TxgbFRI/YYZBagiiq1QxmPGyOX+z3jBn FN7MISxTjPqJXQvS0QQedt2vlcYaj+Z6XdxttU9+qbZtHCQX6e+MaNqwPMssZ4EUqg+u ityqAHxUpDBOZpw7FE/z9R7YYRaGW4nGcvUpDN3TcUz64zOBX6JHWQJK5fqbf/aIV1Cn 1H3DY+GP1IfEC0tjVeTMSlzOHruqbT25SpaYsuG0gm9+6EFIllRup0LQPIEc/RL7lH2W iM4ALF6Jn2UqhTxCasK201+E9T2DenvWRMmZD162JmF+uch2rjJqzCKSkPqOMg050PXV dQ== Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp2120.oracle.com with ESMTP id 2ncgnr5nvb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 31 Oct 2018 21:22:18 +0000 Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w9VLMBjx022485 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 31 Oct 2018 21:22:11 GMT Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w9VLMA31008810; Wed, 31 Oct 2018 21:22:10 GMT Received: from dhcp-10-159-134-86.vpn.oracle.com (/10.159.134.86) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 31 Oct 2018 14:22:09 -0700 From: Qing Zhao Message-Id: <906CF3E1-2CE2-43EA-9AB1-6CD0D2F0CA93@oracle.com> Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: [RFC] GCC support for live-patching Date: Wed, 31 Oct 2018 22:08:00 -0000 In-Reply-To: <980ECBBE-86E9-49EC-A573-96CDCB850BE5@oracle.com> Cc: Martin Jambor , =?utf-8?Q?Martin_Li=C5=A1ka?= , live-patching@vger.kernel.org, Jan Hubicka , richard Biener , rep.dot.nop@gmail.com, andi Kleen , Miroslav Benes , nstange@suse.de To: gcc-patches@gcc.gnu.org References: <5263e463-96d1-7fc5-ddff-26efa82df25f@redhat.com> <20180926150649.GD61973@kam.mff.cuni.cz> <20180926171642.GG61973@kam.mff.cuni.cz> <131EB12C-DC35-4B3C-9F89-40EBA5317261@oracle.com> <20180927085829.GJ61973@kam.mff.cuni.cz> <817E4C4A-F81B-4E09-9645-04E38A1B9E74@oracle.com> <5CB6BDBE-3F49-4BFE-AF10-5E8181C49181@oracle.com> <1a023bdc-28a6-eb41-b449-4d096f12064f@suse.cz> <048D9997-B7AF-444A-BF7E-79944DE8F174@oracle.com> <3E37D3A8-2D19-41C2-BA8A-8F0EFA1B4D5C@oracle.com> <10a54034-279b-a406-8466-55558effbf24@suse.cz> <980ECBBE-86E9-49EC-A573-96CDCB850BE5@oracle.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2018-10/txt/msg02089.txt.bz2 Hi,=20 (resend to CCing more people who provided feedbacks in previous discuss, th= e alias =E2=80=9Clive-patching@vger.kernel.org =E2=80=9D was unreachable) this is the 2nd version of the proposal. the major changes are: 1. change the option name from =E2=80=9C-fease-live-patching=E2=80=9D to = =E2=80=9C-flive-patching=E2=80=9D 2. delete two sub-options, =E2=80=9Cnone=E2=80=9D, =E2=80=9Cinline=E2=80= =9D from the list, only keep =E2=80=9Cinline-only-static=E2=80=9D and =E2= =80=9Cinline-clone=E2=80=9D. 3. add the importance of controlling the number of impacted function list = to control memory consumption for live patching schemes that patch hundreds or thousands processes at the= same time. 4. re-organize the background and motivation sections based on the previou= s feedbacks.=20 Please take a look and let me know any more comments and suggestions. thanks. Qing =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D options to help live patching in GCC (version 2) Qing Zhao 10/31/2018 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 0. Terminology used in this proposal 1. The proposal 2. Two issues in live patching schemes that need compiler support=20 3. Compiler support for live patching 4. Details of the proposal 0. Terminology used in this proposal: impacted function: When the body or the information extracted from the body of a function is=20 used to optimize and change another function, the latter is called an impac= ted=20 function of the former.=20 impacted function list: A list that includes all the impacted functions for a specific function.=20 1. The proposal: Provide two first class options in GCC to help live-patching users. A. an option to control GCC's optimizations to provide a safe=20 compilation for live-patching purpose. At the same time, provides multiple-level control on the length of the impacted function list=20 and run time performance tradeoff. -flive-patching=3D{inline-only-static | inline-clone} When -flive-patching specified without any value, the default value is "inline-clone".=20 B. an option to compute the impacted function lists and dump them for live-patching users.=20=20 -flive-patching-list=3D{func_name | all}{,dump_func_name} This option guides the compiler to compute the list of impacted routines for live patching. It only has effect when it is combined with -flive-patching. when -flive-patching-list is specified without any value, the default value= is "all", i.e, compute the lists of impacted functions for all functions and d= ump=20 them into stdout for the specific -flive-patching option. Refer to Section 4 for more details of the proposal. 2. Two issues in live patching schemes that need compiler support:=20 There are two major issues that need compilers' support in live patching: A. control the number of impacted functions; B. compute and report the impacted function list; A is for the live patching scheme that patches hundreds or thousands multiple-processes in order to control the total memory consumption.=20 B is for the live patching scheme that generates patches from source code level.=20=20 The following is the detailed explanation of these two issues. 2.1. compute and report the impacted function list=20 There are three major kernel live patching tools:=20=20 (https://lwn.net/Articles/734765/ >) * ksplice: http://www.ksplice.com/doc/ksplice.pdf > * kpatch: https://lwn.net/Articles/597123/ > https://github.com/dynup/kpatch > * kGraft:=20=20=20=20 https://pdfs.semanticscholar.org/presentation/af4c/895aa3fef0cc2b501317aaec= 9d91ba2d704c.pdf > They can be classified into two groups depending on the ways to generate the patches: Group A: generate patches at binary level. the binary patches can be=20 automatically generated as following:=20 a collection of tools which convert a source diff patch to a patch module. They work by compiling the kernel both with and without the sou= rce patch, comparing the binaries, and generating a binary patch module whi= ch=20 includes new binary versions of the functions to be replaced. Group A includes ksplice and kpatch. Group B: generate patches at source code level. The source of the patch will be in a single C file, which is created entirely by hand. This C f= ile will be compiled into the final patch module.=20 Group B includes kGraft.=20 The major benefit of the live patching scheme in Group B is, the patches wi= ll be easy to review, easy to maintain since they are C files.=20 Taking kGraft as an example, Source code level patch creation involves the= =20 following three steps:=20 (From Nicolai Stange: nstange@suse.de >) Step 1. Determine the initial set of to be patched functions: a.) Inspect the diff for the fix in question, add any touched=20 functions to the initial set. b.) For each function in the initial set, check whether it has been used by compiler analyses/optimizations to change other functions, an impacted function should be patched at the same time as the=20 original one. add the impacted functions to the initial set. Repeat until the initial set has been stabilized. Step 2. Copy & paste the initial set over to the new live patch sources. Step 3. Make it compile, i.e. recursively copy any needed cpp macro, type,= =20 or functions definition and add references to data objects with static storage duration. The above Step 1b is the first place that needs compiler support to compute and report the list of impacted functions for each function. 2.2. Control the number of impacted functions When the above linux kernel live patching schemes involve modification of o= nly=20 a single copy of text, there are live patching schemes for other applicatio= ns that have to patch thousands of user processes simultaneously. For such live patching scheme, the number of patched functions has a large impact on the = size of used memory. Basically, the OS will have to make a private copy of each = page=20 that is modified in a process's text segment. The more functions that are p= atched, the more likely it is that additional pages will have to be modified. When = the number of processes is huge, it's important to minimize amount of private m= emory=20 consumed by each process. Therefore, it's important to control the number o= f=20 patched functions. There are mainly two factors to decide the number of patched functions: 1) the initial set of patched functions; 2) the impacted functions for each of the functions in 1).=20 The above 2) is the place that needs compiler support to control the number= =20 of impacted functions.=20 3. Compiler support for live patching. As identified in the above section, live patching needs compiler support=20 for the following two issues: A. control the number of impacted functions; B. compute and report the impacted function list; The impacted functions are decided by the compiler optimizations that use the body or the information extracted from the body of a function to change other functions. Such compiler optimizations are usually IPA optimizations.= =20 For example, inlining a function into it's caller, cloning a function and changing it's caller to call this new clone, or extracting a function's=20 pureness/constness information to optimize it's direct or indirect callers, etc.=20 Usually, the more IPA optimizations enabled, the larger the number of impacted functions for each function. In order to control the number of=20 impacted functions, we should provide control to partially enable IPA optimizations on different levels.=20 Only for enabled IPA optimization, we compute and report the impacted funct= ion list for each function. all the other IPA optimizations should be disabled. currently, we have requests for the following two levels of control: level 1: inline-only-static only enable inlining of static functions, disable all other IPA optimizati= ons. This is mainly for the live patching user who has to patch thousands of=20 processes simutaniously to control the memory consumption. level 2: inline-clone Only enable inlining and all optimizations that internally create clone, for example, cloning, ipa-sra, partial inlining, etc.; disable all other IPA optimizations/analyses.=20 This is manly for the live patching users who create patches on source code level. We can definitely extend to other levels later if needed. If run-time perfo= rmance is critical, more IPA optimizations need to be enabled; On the other hand,= =20 if memory consumption is more critical, less IPA optimizations need to be e= nabled. 4. Details of the proposal: What should GCC provide to live-patching users?=20 A. an option to control GCC's optimizations to provide a safe=20 compilation for live-patching purpose. At the same time, provides multiple-level control on the length of the impacted function list=20 and run time performance tradeoff. -flive-patching=3D{only-inline-static|inline-clone} -flive-patching=3Donly-inline-static Only enable inlining of static functions, disable all other IPA=20 optimizations/analyses. As a result, when patching a static routine, all its callers need to be patches as well. -flive-patching=3Dinline-clone Only enable inlining and all optimizations that internally create clone, for example, cloning, ipa-sra, partial inlining, etc.; disable all=20 other IPA optimizations/analyses. As a result, when patching a routine, all its callers and its clones' callers need to be patched as well.=20 When -flive-patching specified without any value, the default value is "inline-clone".=20 B. an option to compute the impacted function lists and dump them for live-patching users.=20=20 -flive-patching-list=3D{func_name|all}{,dump_func_name} This option guides the compiler to compute the list of impacted routines for live patching. It only has effect when it is combined with -flive-patching. -flive-patching-list=3Dfunc_name compute the list of impacted routines for the routine "func_name" and dump = it into stdout. -flive-patching-list=3Dall compute the list of impacted routines for all routines and dump them=20 into stdout. -flive-patching-list=3Dfunc_name,dump_func_name compute the list of impacted routines for the routine "func_name" and dump = it into the file "dump_func_name". -flive-patching-list=3Dall,dump_func_name compute the list of impacted routines for all routines and dump them=20 into the file "dump_func_name". when -flive-patching-list is specified without any value, the default value= is "all", i.e, compute the lists of impacted routines for all routinesand dump= =20 them into stdout.