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=-13.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL 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 9A506C49361 for ; Sat, 19 Jun 2021 09:20:54 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 456BE611CE for ; Sat, 19 Jun 2021 09:20:54 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 456BE611CE Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id C89BF6B0070; Sat, 19 Jun 2021 05:20:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C39806B0072; Sat, 19 Jun 2021 05:20:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B01AC6B0073; Sat, 19 Jun 2021 05:20:53 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0172.hostedemail.com [216.40.44.172]) by kanga.kvack.org (Postfix) with ESMTP id 7F7956B0070 for ; Sat, 19 Jun 2021 05:20:53 -0400 (EDT) Received: from smtpin14.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 1C4B5181AEF0B for ; Sat, 19 Jun 2021 09:20:53 +0000 (UTC) X-FDA: 78269928786.14.214823E Received: from mail-il1-f182.google.com (mail-il1-f182.google.com [209.85.166.182]) by imf12.hostedemail.com (Postfix) with ESMTP id B68DC37A for ; Sat, 19 Jun 2021 09:20:50 +0000 (UTC) Received: by mail-il1-f182.google.com with SMTP id h3so10585076ilc.9 for ; Sat, 19 Jun 2021 02:20:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sDVZ3c/xTpZGtI9erkQPxbYx9+iJ9vOpXLUpVMNI/1E=; b=iHMdMmyEQsXFGONPsrbXeEqTaxCjYY+Hxsr/rW3fMWm9fmLa0dddqDGpxFSGsyqNGo UnnNULKgqQTqPE+3pDD8mO6+L1jPBQ/i8QtZiVGibEXD8enghkDVYBJ9bL/BqIZRE8HJ 7cf7RYJ4aZFwZ1nUpBIX1ZL6Js4uxBtJAh3AS5xjbOHIZLm8A67mlB6WLRqPW5Z7dcm9 y8F3Pv1PozB9Q7LktRb/mRluF1Kw5Tl3kP3Lq6jIIFFvIiNT5B7mUqzPokZAqckBTCPL wl37rREtww+9/IDpoB/pPty7BOwtLg2IoWaAHdGKgv62c3MSfOGxkbAZ+hEjzeWygxUx xGQA== 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; bh=sDVZ3c/xTpZGtI9erkQPxbYx9+iJ9vOpXLUpVMNI/1E=; b=K3ZKUP+iAXIR140q3A+6aY6kXXfnqPzvmApYNujdmfF0GewSvUGsN7iU2Ikgl1bVD1 6TvaUNlrN0aSEol9AS4zxiaT5OsOZMMEa9GcJfsm5FbiyliWzY0YEyucb7LIHLe4+LJu y/34X4gYH9OcmIhc5zhsasShUYzW4IRLkSqlFbJb9+OjjDycRiq/jTf2YXG/NxXcvs8C DyZZGG2PYgFoOJpODmJux1oTrYlKVsF0WQqDW8pufbrxuj600Zlgs1mXXzPFjbMQ9kbT nLkWRT2ilDLbtaCtHDIdWv6FmFFiSSPt3rTmcAtEIJqEo/DTRaNJCpqFcj+ZeVHXNMR/ FE7w== X-Gm-Message-State: AOAM531j5D0u4//otWXcUc9Fksavm+cZWi/clDPZqZ4NG/CIMGMvS0rS bNGjYe4yMr2PG+nYniYc4e9fPIWXmqVRSn9EeYUbHg== X-Google-Smtp-Source: ABdhPJwC/gS2gEWwdpnbyJ8UJU65AE8I+o9uIFLn0OHwp2dbho65Kx5LceLdZla0C3j9jz2Xmz9m+m6Ai/Rn9FTODU4= X-Received: by 2002:a05:6e02:10c3:: with SMTP id s3mr10298743ilj.37.1624094451650; Sat, 19 Jun 2021 02:20:51 -0700 (PDT) MIME-Version: 1.0 References: <20200814213310.42170-1-pcc@google.com> <20200818030021.GM17456@casper.infradead.org> <2ce2125f-5424-63d5-16a2-a4e1da76053e@nvidia.com> In-Reply-To: <2ce2125f-5424-63d5-16a2-a4e1da76053e@nvidia.com> From: Peter Collingbourne Date: Sat, 19 Jun 2021 02:20:40 -0700 Message-ID: Subject: Re: [PATCH v3] mm: introduce reference pages To: John Hubbard Cc: Matthew Wilcox , "Kirill A . Shutemov" , Andrew Morton , Catalin Marinas , Evgenii Stepanov , Linux ARM , Linux Memory Management List , kernel test robot , Linux API , linux-doc@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: B68DC37A X-Stat-Signature: 5frus6r78ah58shax97efrg8st949of6 Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=google.com header.s=20161025 header.b=iHMdMmyE; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf12.hostedemail.com: domain of pcc@google.com designates 209.85.166.182 as permitted sender) smtp.mailfrom=pcc@google.com X-HE-Tag: 1624094450-948899 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: [Apologies for the delay in getting back to you; other work ended up taking priority and now I'm back to looking at this.] On Tue, Aug 18, 2020 at 11:25 AM John Hubbard wrote: > > On 8/17/20 8:00 PM, Matthew Wilcox wrote: > > On Mon, Aug 17, 2020 at 07:31:39PM -0700, John Hubbard wrote: > >>> Real time (s) Max RSS (KiB) > >>> anon 2.237081 107088 > >>> memset 2.252241 112180 > >>> refpage 2.243786 107128 > >>> > >>> We can see that RSS for refpage is almost the same as anon, and real > >>> time overhead is 44% that of memset. > >>> > >> > >> Are some of the numbers stale, maybe? Try as I might, I cannot combine > >> anything above to come up with 44%. :) > > > > You're not trying hard enough ;-) > > > > (2.252241 - 2.237081) / 2.237081 = .00677668801442594166 > > (2.243786 - 2.237081) / 2.237081 = .00299720930981041812 > > .00299720930981041812 / .00677668801442594166 = .44228232189973614648 > > > > tadaa! > > haha, OK then! :) Next time I may try harder, but on the other hand my > interpretation of the results is still "this is a small effect", even > if there is a way to make it sound large by comparing the 3rd significant > digits of the results... > > > > > As I said last time this was posted, I'm just not excited by this. We go > > from having a 0.68% time overhead down to an 0.30% overhead, which just > > doesn't move the needle for me. Maybe there's a better benchmark than > > this to show benefits from this patchset. > > > Remember that this is a "realistic" benchmark, so it's doing plenty of other work besides faulting pages. So I don't think we should expect to see a massive improvement here. I ran the pdfium benchmark again but I couldn't see the same improvements that I got last time. This seems to be because pdfium has since switched to its own allocator, bypassing the system allocator. I think the gains should be larger with the memset optimization that I've implemented, but I'm still in the process of finding a suitable realistic benchmark that uses the system allocator. But I would find a 0.4% perf improvement convincing enough, personally, given that the workload is realistic. Consider a certain large company which spends $billions annually on data centers. In that environment a 0.4% performance improvement on realistic workloads can translate to $millions of savings. And that's not taking into account the memory savings which are important both in mobile environments and in data centers. > Yes, I wonder if there is an artificial workload that just uses refpages > really extensively, maybe we can get some good solid improvements shown > with that? Otherwise, it seems like we've just learned that memset is > actually pretty good in this case. :) Yes, it's possible to see the performance improvement here more clearly with a microbenchmark. I've updated the commit message in v4 to include a microbenchmark program and some performance numbers from it. Peter