From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-12.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 91A54C433DB for ; Tue, 22 Dec 2020 15:34:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5C77F2311D for ; Tue, 22 Dec 2020 15:34:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728016AbgLVPdk (ORCPT ); Tue, 22 Dec 2020 10:33:40 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49604 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727974AbgLVPdk (ORCPT ); Tue, 22 Dec 2020 10:33:40 -0500 Received: from mail-vk1-xa2c.google.com (mail-vk1-xa2c.google.com [IPv6:2607:f8b0:4864:20::a2c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B8EE3C0613D6 for ; Tue, 22 Dec 2020 07:32:59 -0800 (PST) Received: by mail-vk1-xa2c.google.com with SMTP id o195so3106708vka.9 for ; Tue, 22 Dec 2020 07:32:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=sCCWkD/7cQKPFXtewXveIGY2SqGtgyK9cV2bzmLn1iY=; b=eJ9AZPbWNoxrprRr7Td1v3jTzH5E7goKQ08BrweW7k7WC7UYuAREWRWJ1hwoMkL6/v a6S2ulSlqsq9T75ssxl6m4wYB3+0M/Kc8JKlhDYAGGwP8vRu1n5BraDIybrvZ9tzlkGJ WXKksnT1J14sMbzI1C/DATLEyYSkr2cXxIVKSMbDz7r04WK7jVxTdd9uQktNv5F90eaA KSgukhsE1y0aLn4WffVlKr2hzxy7YoVPkGWu/KLi2+gPADfzIcUWcUXsSgvkmOpxQq3c TGxBC4H0o8DmGFUalrBswoSYf4peX5jvvTf9Mtve94lP0Aa16NVm6WAPUswUbtJ93AMP Y2BQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=sCCWkD/7cQKPFXtewXveIGY2SqGtgyK9cV2bzmLn1iY=; b=hW5eiDicmXFYIkWdFZRFeBvr0A86MmQuNFQdlmZzG5qny7NUKXl34SVA7JgJ/ImkAs QKbW/N/ke63CUcAaEaOo3IGcu7dyPjRGZJMa2mX/J/wfmqOqOwBMP86zdSOD1AOvPxWb qeAUXp8eQ9kHyMmt3nZnf8xKlh5UDJKIe9aU9zGh189n8pkMTUvEbS6ZTc25UdHoWktK srbsTn8QVYiMqx+CIYAVz1ipVs5bLeCwHK0sg0FXc3veWA6MHAethEzyOKH2+yY3U1tP XEYIlE0MWePpXB2zq96CmQFnF5V5a7HMiEgI1nQ4H3uxIfio/+58wPEb7VziLGTrcBmJ Cv5g== X-Gm-Message-State: AOAM532p83LwXJSrfPcFZ7wmczMl1glF8+Ds793zxkrCDJ2oI5mHEQAh bg+afj+T1u0QhfwaUTG0LyQSoKj5owK7nm+b+kM= X-Google-Smtp-Source: ABdhPJw9mRX/xeSGCJ1cnXOEv2fpcO1VPs/9HviH6a5y1VLGkIkoB8tS6sbhoTzLipJDioUaypwXyAH3A63WH1enEsg= X-Received: by 2002:a1f:a796:: with SMTP id q144mr8906878vke.19.1608651178945; Tue, 22 Dec 2020 07:32:58 -0800 (PST) MIME-Version: 1.0 References: <20201222121904.50845-1-qianjun.kernel@gmail.com> In-Reply-To: From: jun qian Date: Tue, 22 Dec 2020 23:32:48 +0800 Message-ID: Subject: Re: [PATCH 1/1] mm:improve the performance during fork To: Souptick Joarder Cc: Andrew Morton , Linux-MM , linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Souptick Joarder =E4=BA=8E2020=E5=B9=B412=E6=9C=8822= =E6=97=A5=E5=91=A8=E4=BA=8C =E4=B8=8B=E5=8D=8811:08=E5=86=99=E9=81=93=EF=BC= =9A > > On Tue, Dec 22, 2020 at 5:49 PM wrote: > > > > From: jun qian > > > > In our project, Many business delays come from fork, so > > we started looking for the reason why fork is time-consuming. > > I used the ftrace with function_graph to trace the fork, found > > that the vm_normal_page will be called tens of thousands and > > the execution time of this vm_normal_page function is only a > > few nanoseconds. And the vm_normal_page is not a inline function. > > So I think if the function is inline style, it maybe reduce the > > call time overhead. > > > > I did the following experiment: > > > > I have wrote the c test code, pls ignore the memory leak :) > > Before fork, I will malloc 4G bytes, then acculate the fork > > time. > > > > int main() > > { > > char *p; > > unsigned long long i=3D0; > > float time_use=3D0; > > struct timeval start; > > struct timeval end; > > > > for(i=3D0; i > p =3D (char *)malloc(4096); > > if (p =3D=3D NULL) { > > printf("malloc failed!\n"); > > return 0; > > } > > p[0] =3D 0x55; > > } > > gettimeofday(&start,NULL); > > fork(); > > gettimeofday(&end,NULL); > > > > time_use=3D(end.tv_sec * 1000000 + end.tv_usec) - > > (start.tv_sec * 1000000 + start.tv_usec); > > printf("time_use is %.10f us\n",time_use); > > > > return 0; > > } > > > > We need to compare the changes in the size of vmlinux, the time of > > fork in inline and non-inline cases, and the vm_normal_page will be > > called in many function. So we also need to compare this function's > > size. For examples, the do_wp_page will call vm_normal_page, so I > > also calculated it's size. > > > > inline non-inline diff > > vmlinux size 9709248 bytes 9709824 bytes -576 bytes > > fork time 23475ns 24638ns -4.7% > > Do you have time diff for both parent and child process ? yes, the child time diff and the parent time diff are almost same, just like this, a.out is the test program. ./a.out time_use is 23342.0000000000 us time_use is 23404.0000000000 us > > > do_wp_page size 972 743 +229 > > > > According to the above test data, I think inline vm_normal_page can > > reduce fork execution time. > > > > Signed-off-by: jun qian > > --- > > mm/memory.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/mm/memory.c b/mm/memory.c > > index 7d608765932b..a689bb5d3842 100644 > > --- a/mm/memory.c > > +++ b/mm/memory.c > > @@ -591,7 +591,7 @@ static void print_bad_pte(struct vm_area_struct *vm= a, unsigned long addr, > > * PFNMAP mappings in order to support COWable mappings. > > * > > */ > > -struct page *vm_normal_page(struct vm_area_struct *vma, unsigned long = addr, > > +inline struct page *vm_normal_page(struct vm_area_struct *vma, unsigne= d long addr, > > pte_t pte) > > { > > unsigned long pfn =3D pte_pfn(pte); > > -- > > 2.18.2 > > > > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-12.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8BC90C433DB for ; Tue, 22 Dec 2020 15:33:02 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 05E1922B2B for ; Tue, 22 Dec 2020 15:33:01 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 05E1922B2B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id DB11F6B0068; Tue, 22 Dec 2020 10:33:00 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D63C56B0071; Tue, 22 Dec 2020 10:33:00 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CA03A8D0016; Tue, 22 Dec 2020 10:33:00 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0222.hostedemail.com [216.40.44.222]) by kanga.kvack.org (Postfix) with ESMTP id B84596B0068 for ; Tue, 22 Dec 2020 10:33:00 -0500 (EST) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 70D6F180AD5C5 for ; Tue, 22 Dec 2020 15:33:00 +0000 (UTC) X-FDA: 77621311320.08.net52_240d88e27461 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin08.hostedemail.com (Postfix) with ESMTP id 440971819E773 for ; Tue, 22 Dec 2020 15:33:00 +0000 (UTC) X-HE-Tag: net52_240d88e27461 X-Filterd-Recvd-Size: 6315 Received: from mail-vk1-f176.google.com (mail-vk1-f176.google.com [209.85.221.176]) by imf20.hostedemail.com (Postfix) with ESMTP for ; Tue, 22 Dec 2020 15:32:59 +0000 (UTC) Received: by mail-vk1-f176.google.com with SMTP id u67so3109354vkb.5 for ; Tue, 22 Dec 2020 07:32:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=sCCWkD/7cQKPFXtewXveIGY2SqGtgyK9cV2bzmLn1iY=; b=eJ9AZPbWNoxrprRr7Td1v3jTzH5E7goKQ08BrweW7k7WC7UYuAREWRWJ1hwoMkL6/v a6S2ulSlqsq9T75ssxl6m4wYB3+0M/Kc8JKlhDYAGGwP8vRu1n5BraDIybrvZ9tzlkGJ WXKksnT1J14sMbzI1C/DATLEyYSkr2cXxIVKSMbDz7r04WK7jVxTdd9uQktNv5F90eaA KSgukhsE1y0aLn4WffVlKr2hzxy7YoVPkGWu/KLi2+gPADfzIcUWcUXsSgvkmOpxQq3c TGxBC4H0o8DmGFUalrBswoSYf4peX5jvvTf9Mtve94lP0Aa16NVm6WAPUswUbtJ93AMP Y2BQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=sCCWkD/7cQKPFXtewXveIGY2SqGtgyK9cV2bzmLn1iY=; b=Fymd/IlwvhbzrvKIVsKiPQsP2DNnAxlcg2Ofch2wul29cMdDyLtN5Wy8rrBtR+ISGA YPK78oLBuAxJWWw+FffloFp+nUxtmomc6YMJps74Vg3FKysHUnNlmhotbWgtlsesrIVl CsfC56L9Qh+wA/lHxcOl3+lq6Csd32yqr/c+km8hYUoyNVaqo646uhJ26wYEPgtl6DHk L9Lh+6VsVUwQDPQv1UUZB75JdNk+K7gHpv22T54Ml39Z+yKYwHvA48lFUjjuNtFVmSdY Y6M22U0U4RFDWTEPViNGmksuaUGby/cyRov2Oj5PSQYQOG69plwaJt3p420RDU0lk9P4 EjrA== X-Gm-Message-State: AOAM533ahPvwHomAeE7tfjmYqm55TdWX4+DrFry1vDk9ALwva0ngfYD+ KQyQzHVwCSAEqq/H5ybbpzhb3nFW99+quaffls8= X-Google-Smtp-Source: ABdhPJw9mRX/xeSGCJ1cnXOEv2fpcO1VPs/9HviH6a5y1VLGkIkoB8tS6sbhoTzLipJDioUaypwXyAH3A63WH1enEsg= X-Received: by 2002:a1f:a796:: with SMTP id q144mr8906878vke.19.1608651178945; Tue, 22 Dec 2020 07:32:58 -0800 (PST) MIME-Version: 1.0 References: <20201222121904.50845-1-qianjun.kernel@gmail.com> In-Reply-To: From: jun qian Date: Tue, 22 Dec 2020 23:32:48 +0800 Message-ID: Subject: Re: [PATCH 1/1] mm:improve the performance during fork To: Souptick Joarder Cc: Andrew Morton , Linux-MM , linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Souptick Joarder =E4=BA=8E2020=E5=B9=B412=E6=9C=8822= =E6=97=A5=E5=91=A8=E4=BA=8C =E4=B8=8B=E5=8D=8811:08=E5=86=99=E9=81=93=EF=BC= =9A > > On Tue, Dec 22, 2020 at 5:49 PM wrote: > > > > From: jun qian > > > > In our project, Many business delays come from fork, so > > we started looking for the reason why fork is time-consuming. > > I used the ftrace with function_graph to trace the fork, found > > that the vm_normal_page will be called tens of thousands and > > the execution time of this vm_normal_page function is only a > > few nanoseconds. And the vm_normal_page is not a inline function. > > So I think if the function is inline style, it maybe reduce the > > call time overhead. > > > > I did the following experiment: > > > > I have wrote the c test code, pls ignore the memory leak :) > > Before fork, I will malloc 4G bytes, then acculate the fork > > time. > > > > int main() > > { > > char *p; > > unsigned long long i=3D0; > > float time_use=3D0; > > struct timeval start; > > struct timeval end; > > > > for(i=3D0; i > p =3D (char *)malloc(4096); > > if (p =3D=3D NULL) { > > printf("malloc failed!\n"); > > return 0; > > } > > p[0] =3D 0x55; > > } > > gettimeofday(&start,NULL); > > fork(); > > gettimeofday(&end,NULL); > > > > time_use=3D(end.tv_sec * 1000000 + end.tv_usec) - > > (start.tv_sec * 1000000 + start.tv_usec); > > printf("time_use is %.10f us\n",time_use); > > > > return 0; > > } > > > > We need to compare the changes in the size of vmlinux, the time of > > fork in inline and non-inline cases, and the vm_normal_page will be > > called in many function. So we also need to compare this function's > > size. For examples, the do_wp_page will call vm_normal_page, so I > > also calculated it's size. > > > > inline non-inline diff > > vmlinux size 9709248 bytes 9709824 bytes -576 bytes > > fork time 23475ns 24638ns -4.7% > > Do you have time diff for both parent and child process ? yes, the child time diff and the parent time diff are almost same, just like this, a.out is the test program. ./a.out time_use is 23342.0000000000 us time_use is 23404.0000000000 us > > > do_wp_page size 972 743 +229 > > > > According to the above test data, I think inline vm_normal_page can > > reduce fork execution time. > > > > Signed-off-by: jun qian > > --- > > mm/memory.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/mm/memory.c b/mm/memory.c > > index 7d608765932b..a689bb5d3842 100644 > > --- a/mm/memory.c > > +++ b/mm/memory.c > > @@ -591,7 +591,7 @@ static void print_bad_pte(struct vm_area_struct *vm= a, unsigned long addr, > > * PFNMAP mappings in order to support COWable mappings. > > * > > */ > > -struct page *vm_normal_page(struct vm_area_struct *vma, unsigned long = addr, > > +inline struct page *vm_normal_page(struct vm_area_struct *vma, unsigne= d long addr, > > pte_t pte) > > { > > unsigned long pfn =3D pte_pfn(pte); > > -- > > 2.18.2 > > > >