All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wei Yang <richardw.yang@linux.intel.com>
To: Rik van Riel <riel@surriel.com>
Cc: Wei Yang <richardw.yang@linux.intel.com>,
	akpm@linux-foundation.org, kirill.shutemov@linux.intel.com,
	jglisse@redhat.com, mike.kravetz@oracle.com,
	khlebnikov@yandex-team.ru, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm/rmap.c: reuse mergeable anon_vma as parent when fork
Date: Sat, 5 Oct 2019 07:49:07 +0800	[thread overview]
Message-ID: <20191004234907.GC15415@richard> (raw)
In-Reply-To: <9358295b1d9cc173940a58038123128b4dafc5d0.camel@surriel.com>

On Fri, Oct 04, 2019 at 07:45:26PM -0400, Rik van Riel wrote:
>On Sat, 2019-10-05 at 00:06 +0800, Wei Yang wrote:
>> 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.
>> 
>> Signed-off-by: Wei Yang <richardw.yang@linux.intel.com>
>
>Acked-by: Rik van Riel <riel@surriel.com>
>

Thanks

>-- 
>All Rights Reversed.



-- 
Wei Yang
Help you, Help me


      reply	other threads:[~2019-10-04 23:49 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-04 16:06 [PATCH] mm/rmap.c: reuse mergeable anon_vma as parent when fork Wei Yang
2019-10-04 16:11 ` Matthew Wilcox
2019-10-04 22:33   ` Wei Yang
2019-10-04 23:48   ` Wei Yang
2019-10-05  1:15     ` Matthew Wilcox
2019-10-05 12:35       ` Wei Yang
2019-10-04 16:33 ` Konstantin Khlebnikov
2019-10-04 22:38   ` Wei Yang
2019-10-04 23:45 ` Rik van Riel
2019-10-04 23:49   ` Wei Yang [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191004234907.GC15415@richard \
    --to=richardw.yang@linux.intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=jglisse@redhat.com \
    --cc=khlebnikov@yandex-team.ru \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mike.kravetz@oracle.com \
    --cc=riel@surriel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.