Received: by 2002:a5b:505:0:0:0:0:0 with SMTP id o5csp572091ybp; Fri, 11 Oct 2019 00:28:26 -0700 (PDT) X-Google-Smtp-Source: APXvYqwP/sS99ayl0mUodKeyqpDOIAC1kOXVvW4x92J4iXGUKdSBUgTkG+T4xNV45oiEVH3d+7Hd X-Received: by 2002:a05:6402:2c5:: with SMTP id b5mr12318021edx.45.1570778906809; Fri, 11 Oct 2019 00:28:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1570778906; cv=none; d=google.com; s=arc-20160816; b=BrvFJ06n2QVd+y0uJOnD/AAjkh4fO1nPar4QgvQZkZJcFBqMAAFWgzZraOX1EIHlHY f3pdPrExdLcY0c0WNJg+mKG9Lt7ClPttaxoXX++HN+aGKaWzve/fZFkcDDL5iW7ZJckE fvrwz8Amr8RzDesozgyeb2Ll1RAOG5RStkRyM/4J2siPIFpd8cjZMU2//thKJHcE/hNO 9yGGSirhf42cq2myMyPyzDyJCwZf42bbTuqvirJWA9FzHvNv47oy0cN8/pGEF5kg9FgD USAvcSYsmMF3cgZH1rz22UAiYqOndrvcFEH4D27Fc/DnbmBOYOMZ2xdXO3tkZTnihEGx dAUA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from; bh=QWeG/Pkz6YNw+Ybft7hJxpPhf0FfjMBos074l7JI1j8=; b=xD9y9g1vG7F0uzDtd7duD/mVn0p9FZ2VjPLiVIPZc15W2p8TkuImmrHuj+id4p/QjG fb8drkQ6uc6JnK2TITR7j0ifN8wHWDeP+k4L5rZbZxlrQQkpsg1NmdeCTPcd6VW6rE6Z H1Bf0b8fa2L9FZOjhGE25brN3YmbF7W7B+tWA7PXkTNl0CymxesOESQzh4RPJcjv0uo/ RNBgUeHNWnWulaRtftQVL6Qib2MBHIR4Bu+bdIsdgy6N6vJFFYpCqmUOM7i5vvWrWHkp khiGa3aSvmfFow0R8zoggDrZfI2KXTcvOa2xTOi55zksk9jFbdiNVy/10B1hsIMak9EC 2brw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d48si5087819eda.383.2019.10.11.00.28.03; Fri, 11 Oct 2019 00:28:26 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727696AbfJKHYE (ORCPT + 99 others); Fri, 11 Oct 2019 03:24:04 -0400 Received: from mga18.intel.com ([134.134.136.126]:3767 "EHLO mga18.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726679AbfJKHYD (ORCPT ); Fri, 11 Oct 2019 03:24:03 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Oct 2019 00:24:03 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.67,283,1566889200"; d="scan'208";a="219306373" Received: from richard.sh.intel.com (HELO localhost) ([10.239.159.54]) by fmsmga004.fm.intel.com with ESMTP; 11 Oct 2019 00:24:01 -0700 From: Wei Yang To: akpm@linux-foundation.org, kirill.shutemov@linux.intel.com, jglisse@redhat.com, mike.kravetz@oracle.com, riel@surriel.com, khlebnikov@yandex-team.ru, cai@lca.pw, shakeelb@google.com Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Wei Yang Subject: [Patch v4 2/2] mm/rmap.c: reuse mergeable anon_vma as parent when fork Date: Fri, 11 Oct 2019 15:22:56 +0800 Message-Id: <20191011072256.16275-2-richardw.yang@linux.intel.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20191011072256.16275-1-richardw.yang@linux.intel.com> References: <20191011072256.16275-1-richardw.yang@linux.intel.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org In function __anon_vma_prepare(), we will try to find anon_vma if it is possible to reuse it. While on fork, the logic is different. Since commit 5beb49305251 ("mm: change anon_vma linking to fix multi-process server scalability issue"), function anon_vma_clone() tries to allocate new anon_vma for child process. But the logic here will allocate a new anon_vma for each vma, even in parent this vma is mergeable and share the same anon_vma with its sibling. This may do better for scalability issue, while it is not necessary to do so especially after interval tree is used. Commit 7a3ef208e662 ("mm: prevent endless growth of anon_vma hierarchy") tries to reuse some anon_vma by counting child anon_vma and attached vmas. While for those mergeable anon_vmas, we can just reuse it and not necessary to go through the logic. After this change, kernel build test reduces 20% anon_vma allocation. Do the same kernel build test, it shows run time in sys reduced 11.6%. Origin: real 2m50.467s user 17m52.002s sys 1m51.953s real 2m48.662s user 17m55.464s sys 1m50.553s real 2m51.143s user 17m59.687s sys 1m53.600s Patched: real 2m39.933s user 17m1.835s sys 1m38.802s real 2m39.321s user 17m1.634s sys 1m39.206s real 2m39.575s user 17m1.420s sys 1m38.845s Signed-off-by: Wei Yang --- mm/rmap.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/mm/rmap.c b/mm/rmap.c index c34414567474..2c13e2bfd393 100644 --- a/mm/rmap.c +++ b/mm/rmap.c @@ -268,6 +268,19 @@ int anon_vma_clone(struct vm_area_struct *dst, struct vm_area_struct *src) { struct anon_vma_chain *avc, *pavc; struct anon_vma *root = NULL; + struct vm_area_struct *prev = dst->vm_prev, *pprev = src->vm_prev; + + /* + * If parent share anon_vma with its vm_prev, keep this sharing in in + * child. + * + * 1. Parent has vm_prev, which implies we have vm_prev. + * 2. Parent and its vm_prev have the same anon_vma. + */ + if (!dst->anon_vma && src->anon_vma && + pprev && pprev->anon_vma == src->anon_vma) + dst->anon_vma = prev->anon_vma; + list_for_each_entry_reverse(pavc, &src->anon_vma_chain, same_vma) { struct anon_vma *anon_vma; -- 2.17.1