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=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no 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 625B0C433DB for ; Tue, 22 Dec 2020 18:42:57 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id E6578224BE for ; Tue, 22 Dec 2020 18:42:56 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E6578224BE Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=ACULAB.COM Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 648388D0013; Tue, 22 Dec 2020 13:42:56 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5F8B78D000A; Tue, 22 Dec 2020 13:42:56 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 535658D0013; Tue, 22 Dec 2020 13:42:56 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0182.hostedemail.com [216.40.44.182]) by kanga.kvack.org (Postfix) with ESMTP id 3C94B8D000A for ; Tue, 22 Dec 2020 13:42:56 -0500 (EST) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id F3EC78249980 for ; Tue, 22 Dec 2020 18:42:55 +0000 (UTC) X-FDA: 77621789952.27.flag53_160646b27462 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin27.hostedemail.com (Postfix) with ESMTP id D8C603D668 for ; Tue, 22 Dec 2020 18:42:55 +0000 (UTC) X-HE-Tag: flag53_160646b27462 X-Filterd-Recvd-Size: 3036 Received: from eu-smtp-delivery-151.mimecast.com (eu-smtp-delivery-151.mimecast.com [207.82.80.151]) by imf40.hostedemail.com (Postfix) with ESMTP for ; Tue, 22 Dec 2020 18:42:55 +0000 (UTC) Received: from AcuMS.aculab.com (156.67.243.126 [156.67.243.126]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-216-NzeuVMnNNqCo6nmnfbI2nQ-1; Tue, 22 Dec 2020 18:42:50 +0000 X-MC-Unique: NzeuVMnNNqCo6nmnfbI2nQ-1 Received: from AcuMS.Aculab.com (fd9f:af1c:a25b:0:43c:695e:880f:8750) by AcuMS.aculab.com (fd9f:af1c:a25b:0:43c:695e:880f:8750) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 22 Dec 2020 18:42:49 +0000 Received: from AcuMS.Aculab.com ([fe80::43c:695e:880f:8750]) by AcuMS.aculab.com ([fe80::43c:695e:880f:8750%12]) with mapi id 15.00.1347.000; Tue, 22 Dec 2020 18:42:49 +0000 From: David Laight To: "'qianjun.kernel@gmail.com'" , "akpm@linux-foundation.org" CC: "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" Subject: RE: [PATCH 1/1] mm:improve the performance during fork Thread-Topic: [PATCH 1/1] mm:improve the performance during fork Thread-Index: AQHW2FzhXFuZ8KmDFkCjkZcJPkqDtKoDcq7g Date: Tue, 22 Dec 2020 18:42:49 +0000 Message-ID: References: <20201222121904.50845-1-qianjun.kernel@gmail.com> In-Reply-To: <20201222121904.50845-1-qianjun.kernel@gmail.com> Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.202.205.107] MIME-Version: 1.0 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=C51A453 smtp.mailfrom=david.laight@aculab.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: aculab.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.385310, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: From: qianjun > Sent: 22 December 2020 12:19 >=20 > 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. Beware of taking timings from ftrace function trace. The cost of the tracing is significant. You can get sensible numbers if you only trace very specific functions. Slightly annoyingly the output format changes if you enable the function exit trace - useful for the timestamp. ISTR it is possible to get the process id traced if you fiddle with enough options. =09David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1= PT, UK Registration No: 1397386 (Wales)