All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rik van Riel <riel@redhat.com>
To: Konstantin Khlebnikov <koct9i@gmail.com>,
	linux-mm <linux-mm@kvack.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Cc: Andrea Arcangeli <aarcange@redhat.com>,
	Tim Hartrick <tim@edgecast.com>,
	Daniel Forrest <dan.forrest@ssec.wisc.edu>,
	Hugh Dickins <hughd@google.com>, Michal Hocko <mhocko@suse.cz>,
	Michel Lespinasse <walken@google.com>,
	Vlastimil Babka <vbabka@suse.cz>
Subject: Re: [PATCH v4] mm: prevent endless growth of anon_vma hierarchy
Date: Wed, 17 Dec 2014 11:32:49 -0500	[thread overview]
Message-ID: <5491B031.3070107@redhat.com> (raw)
In-Reply-To: <20141217085737.16381.75639.stgit@zurg>

On 12/17/2014 02:57 AM, Konstantin Khlebnikov wrote:

> @@ -236,6 +240,13 @@ static inline void unlock_anon_vma_root(struct anon_vma *root)
>  /*
>   * Attach the anon_vmas from src to dst.
>   * Returns 0 on success, -ENOMEM on failure.
> + *
> + * If dst->anon_vma is NULL this function tries to find and reuse existing
> + * anon_vma which has no vmas and only one child anon_vma. This prevents
> + * degradation of anon_vma hierarchy to endless linear chain in case of
> + * constantly forking task. In other hand anon_vma with more than one child
> + * isn't reused even if was no alive vma, thus rmap walker has a good chance
> + * to avoid scanning whole hieraryhy when it searches where page is mapped.
                              ^^^^^^^^^
                              hierarchy

Other than that:

Reviewed-by: Rik van Riel <riel@redhat.com>


Thanks for fixing this long standing issue, Konstantin.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: Rik van Riel <riel@redhat.com>
To: Konstantin Khlebnikov <koct9i@gmail.com>,
	linux-mm <linux-mm@kvack.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Cc: Andrea Arcangeli <aarcange@redhat.com>,
	Tim Hartrick <tim@edgecast.com>,
	Daniel Forrest <dan.forrest@ssec.wisc.edu>,
	Hugh Dickins <hughd@google.com>, Michal Hocko <mhocko@suse.cz>,
	Michel Lespinasse <walken@google.com>,
	Vlastimil Babka <vbabka@suse.cz>
Subject: Re: [PATCH v4] mm: prevent endless growth of anon_vma hierarchy
Date: Wed, 17 Dec 2014 11:32:49 -0500	[thread overview]
Message-ID: <5491B031.3070107@redhat.com> (raw)
In-Reply-To: <20141217085737.16381.75639.stgit@zurg>

On 12/17/2014 02:57 AM, Konstantin Khlebnikov wrote:

> @@ -236,6 +240,13 @@ static inline void unlock_anon_vma_root(struct anon_vma *root)
>  /*
>   * Attach the anon_vmas from src to dst.
>   * Returns 0 on success, -ENOMEM on failure.
> + *
> + * If dst->anon_vma is NULL this function tries to find and reuse existing
> + * anon_vma which has no vmas and only one child anon_vma. This prevents
> + * degradation of anon_vma hierarchy to endless linear chain in case of
> + * constantly forking task. In other hand anon_vma with more than one child
> + * isn't reused even if was no alive vma, thus rmap walker has a good chance
> + * to avoid scanning whole hieraryhy when it searches where page is mapped.
                              ^^^^^^^^^
                              hierarchy

Other than that:

Reviewed-by: Rik van Riel <riel@redhat.com>


Thanks for fixing this long standing issue, Konstantin.

  reply	other threads:[~2014-12-17 17:24 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-17  7:57 [PATCH v4] mm: prevent endless growth of anon_vma hierarchy Konstantin Khlebnikov
2014-12-17  7:57 ` Konstantin Khlebnikov
2014-12-17 16:32 ` Rik van Riel [this message]
2014-12-17 16:32   ` Rik van Riel

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=5491B031.3070107@redhat.com \
    --to=riel@redhat.com \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=dan.forrest@ssec.wisc.edu \
    --cc=hughd@google.com \
    --cc=koct9i@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.cz \
    --cc=tim@edgecast.com \
    --cc=vbabka@suse.cz \
    --cc=walken@google.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.