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=-11.4 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,URIBL_BLOCKED,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 86B02C47420 for ; Fri, 2 Oct 2020 00:09:17 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 2D6BD2168B for ; Fri, 2 Oct 2020 00:09:17 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="X+sw1RIw" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2D6BD2168B 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 A76DE6B009C; Thu, 1 Oct 2020 20:09:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9D97A6B009E; Thu, 1 Oct 2020 20:09:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8525C6B009F; Thu, 1 Oct 2020 20:09:16 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0039.hostedemail.com [216.40.44.39]) by kanga.kvack.org (Postfix) with ESMTP id 43D536B009C for ; Thu, 1 Oct 2020 20:09:16 -0400 (EDT) Received: from smtpin18.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id E4563180AD801 for ; Fri, 2 Oct 2020 00:09:15 +0000 (UTC) X-FDA: 77325050670.18.jail43_300366c2719f Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin18.hostedemail.com (Postfix) with ESMTP id BDBCC100ED586 for ; Fri, 2 Oct 2020 00:09:15 +0000 (UTC) X-HE-Tag: jail43_300366c2719f X-Filterd-Recvd-Size: 8629 Received: from mail-il1-f195.google.com (mail-il1-f195.google.com [209.85.166.195]) by imf07.hostedemail.com (Postfix) with ESMTP for ; Fri, 2 Oct 2020 00:09:15 +0000 (UTC) Received: by mail-il1-f195.google.com with SMTP id t12so200272ilh.3 for ; Thu, 01 Oct 2020 17:09:15 -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=SKmdoWvcoH054ieUmUn071qqw8A/m5uf6wtD7bMmYko=; b=X+sw1RIw3DPYL39kYpPkOfnoG49QnA+1BLDx3z5vyVL5igSZLErLIR2DlIwC0mC4nI 8R+VEgEhd4ovTkGh8wczWav2bau0zRc84DRMlxb2n0Dm/5mv4RcbhMCdA1cRtWpGAnve aj6063apIjx14YrF/V9Jz86YXUA56vWci8btoM2LfzJkubEywRNQqUQUWDL4WNfIMIwn sS5sfcDDaAy/Bz0nXdTYQONveOqAnqDOSHcGOz73kyHn0TmQ4P2fNMr0tP+zKZI/VODd TIm/1Vp7NnxwDp+ZfEJ5xZyU7hnlvTANmfr9nYlYYBP4xM3bQtwb+v+fq6QpDx0EJTRR DCFg== 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=SKmdoWvcoH054ieUmUn071qqw8A/m5uf6wtD7bMmYko=; b=PAKwe8Not5a6jZgu2GT3oSLVJB5P40frD5x2/gDB0nuzgLsA3tV9ujoC3LUjsQVdnx QRjxX2Pomb5inpEpK7l1YCGxmlDsHNP+kDEv1wrsS6eGbbbJJwpU7G54ztUwPnhkrjDA nQ7PjLQU5RC96yyMELqzmjCAmJg7vx9OabriS5+a+Y0ClutLRg3H5YUkq/3yi4w9/X3+ hKoNOZoIQDtpc4dfh1t558K0O03U68OpvhNdp3GUoPtLGgCryoyKnFlDSHYfcvPYjN0z fUu8mfMtM2/itVfDyUJZdiuuP5a4jYosIQw0AfbMPa5L5IeIAixYQRrv6sxT857zI6mA 2HDA== X-Gm-Message-State: AOAM531KT5BiZmkbVbvYI94GXzzH2XIS8nDCJu+npHJ5lB03yIQR1QSU nH+t07jPknN8vYdTbY6ZlKPQuM0WpX+o9/ynk2R26A== X-Google-Smtp-Source: ABdhPJyIaoez+xEgtDZBjl//yNKtp8GR6Y6g1HLTO9Gc6f31B7cO30jtfb+DhJiAfj4DKYKo3b6YMhdFVzymm1Qymu0= X-Received: by 2002:a92:ba4d:: with SMTP id o74mr4690236ili.205.1601597354132; Thu, 01 Oct 2020 17:09:14 -0700 (PDT) MIME-Version: 1.0 References: <20200930222130.4175584-1-kaleshsingh@google.com> <20200930223207.5xepuvu6wr6xw5bb@black.fi.intel.com> <20201001122706.jp2zr23a43hfomyg@black.fi.intel.com> In-Reply-To: From: Lokesh Gidra Date: Thu, 1 Oct 2020 17:09:02 -0700 Message-ID: Subject: Re: [PATCH 0/5] Speed up mremap on large regions To: Kalesh Singh , "Kirill A. Shutemov" Cc: Suren Baghdasaryan , Minchan Kim , Joel Fernandes , "Cc: Android Kernel" , Catalin Marinas , Will Deacon , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "the arch/x86 maintainers" , "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 , "moderated list:ARM64 PORT (AARCH64 ARCHITECTURE)" , "open list:MEMORY MANAGEMENT" , "open list:KERNEL SELFTEST FRAMEWORK" Content-Type: text/plain; charset="UTF-8" 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 Thu, Oct 1, 2020 at 9:00 AM Kalesh Singh wrote: > > On Thu, Oct 1, 2020 at 8:27 AM Kirill A. Shutemov > wrote: > > > > 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. > mremap is indeed the biggest contributor to the GC pause. It has to take place in what is typically known as a 'stop-the-world' pause, wherein all application threads are paused. During this pause the GC thread flips the GC roots (threads' stacks, globals etc.), and then resumes threads along with concurrent compaction of the heap.This GC-root flip differs depending on which compaction algorithm is being used. In our case it involves updating object references in threads' stacks and remapping java heap to a different location. The threads' stacks can be handled in parallel with the mremap. Therefore, the dominant factor is indeed the cost of mremap. From patches 2 and 4, it is clear that remapping 1GB without this optimization will take ~9ms on arm64. Although this mremap has to happen only once every GC cycle, and the typical size is also not going to be more than a GB or 2, pausing application threads for ~9ms is guaranteed to cause jitters. OTOH, with this optimization, mremap is reduced to ~60us, which is a totally acceptable pause time. Unfortunately, implementation of the new GC algorithm hasn't yet reached the point where I can quantify the effect of this optimization. But I can confirm that without this optimization the new GC will not be approved. > Lokesh on this thread would be better able to answer this. I'll let > him weigh in here. > Thanks, Kalesh > > > > -- > > Kirill A. Shutemov > > > > -- > > To unsubscribe from this group and stop receiving emails from it, send an email to kernel-team+unsubscribe@android.com. > >