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.7 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED 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 C64FBC4727F for ; Thu, 1 Oct 2020 12:27:31 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3669E20B1F for ; Thu, 1 Oct 2020 12:27:30 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3669E20B1F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 4FFA46B005C; Thu, 1 Oct 2020 08:27:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4ACBF6B0062; Thu, 1 Oct 2020 08:27:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 34E316B0068; Thu, 1 Oct 2020 08:27:30 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0069.hostedemail.com [216.40.44.69]) by kanga.kvack.org (Postfix) with ESMTP id 18C5F6B005C for ; Thu, 1 Oct 2020 08:27:30 -0400 (EDT) Received: from smtpin20.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id BEA5833CD for ; Thu, 1 Oct 2020 12:27:29 +0000 (UTC) X-FDA: 77323282218.20.shoes40_5c0ecea2719b Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin20.hostedemail.com (Postfix) with ESMTP id 87CC9180C07AB for ; Thu, 1 Oct 2020 12:27:29 +0000 (UTC) X-HE-Tag: shoes40_5c0ecea2719b X-Filterd-Recvd-Size: 5486 Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by imf21.hostedemail.com (Postfix) with ESMTP for ; Thu, 1 Oct 2020 12:27:28 +0000 (UTC) IronPort-SDR: AG+OpGa9lah1MK7dEur7O09CuYqMOdH8IeMBgyBHsaoP704IFYdwpCVcSBNh0/m9YRywWfAFrN tt/TszpsQtFg== X-IronPort-AV: E=McAfee;i="6000,8403,9760"; a="163564164" X-IronPort-AV: E=Sophos;i="5.77,323,1596524400"; d="scan'208";a="163564164" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Oct 2020 05:27:17 -0700 IronPort-SDR: vYQlnFQDsSeVVFoJ8EgOROs7Pwdn8XJOQwxW3/B9d3MJcpTWEEUP/POGl82D5k9JxBIIN2EbId 3+0Q3exN2QZg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.77,323,1596524400"; d="scan'208";a="514699410" Received: from black.fi.intel.com ([10.237.72.28]) by fmsmga006.fm.intel.com with ESMTP; 01 Oct 2020 05:27:08 -0700 Received: by black.fi.intel.com (Postfix, from userid 1000) id 31B46327; Thu, 1 Oct 2020 15:27:06 +0300 (EEST) Date: Thu, 1 Oct 2020 15:27:06 +0300 From: "Kirill A. Shutemov" To: Lokesh Gidra Cc: Kalesh Singh , Suren Baghdasaryan , Minchan Kim , Joel Fernandes , kernel-team@android.com, Catalin Marinas , Will Deacon , Thomas Gleixner , Ingo Molnar , Borislav Petkov , x86@kernel.org, "H. Peter Anvin" , Andrew Morton , Shuah Khan , "Aneesh Kumar K.V" , Kees Cook , Peter Zijlstra , Sami Tolvanen , Masahiro Yamada , Arnd Bergmann , Frederic Weisbecker , Krzysztof Kozlowski , Hassan Naveed , Christian Brauner , Mark Rutland , Mike Rapoport , Gavin Shan , Zhenyu Ye , Jia He , John Hubbard , William Kucharski , Sandipan Das , Ralph Campbell , Mina Almasry , Ram Pai , Dave Hansen , Kamalesh Babulal , Masami Hiramatsu , Brian Geffon , SeongJae Park , linux-kernel , linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org, linux-kselftest@vger.kernel.org Subject: Re: [PATCH 0/5] Speed up mremap on large regions Message-ID: <20201001122706.jp2zr23a43hfomyg@black.fi.intel.com> References: <20200930222130.4175584-1-kaleshsingh@google.com> <20200930223207.5xepuvu6wr6xw5bb@black.fi.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: On Wed, Sep 30, 2020 at 03:42:17PM -0700, Lokesh Gidra wrote: > On Wed, Sep 30, 2020 at 3:32 PM Kirill A. Shutemov > wrote: > > > > On Wed, Sep 30, 2020 at 10:21:17PM +0000, Kalesh Singh wrote: > > > mremap time can be optimized by moving entries at the PMD/PUD level if > > > the source and destination addresses are PMD/PUD-aligned and > > > PMD/PUD-sized. Enable moving at the PMD and PUD levels on arm64 and > > > x86. Other architectures where this type of move is supported and known to > > > be safe can also opt-in to these optimizations by enabling HAVE_MOVE_PMD > > > and HAVE_MOVE_PUD. > > > > > > Observed Performance Improvements for remapping a PUD-aligned 1GB-sized > > > region on x86 and arm64: > > > > > > - HAVE_MOVE_PMD is already enabled on x86 : N/A > > > - Enabling HAVE_MOVE_PUD on x86 : ~13x speed up > > > > > > - Enabling HAVE_MOVE_PMD on arm64 : ~ 8x speed up > > > - Enabling HAVE_MOVE_PUD on arm64 : ~19x speed up > > > > > > Altogether, HAVE_MOVE_PMD and HAVE_MOVE_PUD > > > give a total of ~150x speed up on arm64. > > > > Is there a *real* workload that benefit from HAVE_MOVE_PUD? > > > We have a Java garbage collector under development which requires > moving physical pages of multi-gigabyte heap using mremap. During this > move, the application threads have to be paused for correctness. It is > critical to keep this pause as short as possible to avoid jitters > during user interaction. This is where HAVE_MOVE_PUD will greatly > help. Any chance to quantify the effect of mremap() with and without HAVE_MOVE_PUD? I doubt it's a major contributor to the GC pause. I expect you need to move tens of gigs to get sizable effect. And if your GC routinely moves tens of gigs, maybe problem somewhere else? I'm asking for numbers, because increase in complexity comes with cost. If it doesn't provide an substantial benefit to a real workload maintaining the code forever doesn't make sense. -- Kirill A. Shutemov