From: Mel Gorman <mgorman@suse.de>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: Andrew Morton <akpm@linux-foundation.org>,
J?rn Engel <joern@logfs.org>,
Michel Lespinasse <walken@google.com>,
Hugh Dickins <hughd@google.com>, Rik van Riel <riel@redhat.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Michal Hocko <mhocko@suse.cz>,
linux-mm@kvack.org
Subject: Re: [PATCH v2 2/7] mm: munlock: remove unnecessary call to lru_add_drain()
Date: Mon, 19 Aug 2013 15:48:53 +0100 [thread overview]
Message-ID: <20130819144853.GB23002@suse.de> (raw)
In-Reply-To: <1376915022-12741-3-git-send-email-vbabka@suse.cz>
On Mon, Aug 19, 2013 at 02:23:37PM +0200, Vlastimil Babka wrote:
> In munlock_vma_range(), lru_add_drain() is currently called in a loop before
> each munlock_vma_page() call.
> This is suboptimal for performance when munlocking many pages. The benefits
> of per-cpu pagevec for batching the LRU putback are removed since the pagevec
> only holds at most one page from the previous loop's iteration.
>
> The lru_add_drain() call also does not serve any purposes for correctness - it
> does not even drain pagavecs of all cpu's. The munlock code already expects
> and handles situations where a page cannot be isolated from the LRU (e.g.
> because it is on some per-cpu pagevec).
>
> The history of the (not commented) call also suggest that it appears there as
> an oversight rather than intentionally. Before commit ff6a6da6 ("mm: accelerate
> munlock() treatment of THP pages") the call happened only once upon entering the
> function. The commit has moved the call into the while loope. So while the
> other changes in the commit improved munlock performance for THP pages, it
> introduced the abovementioned suboptimal per-cpu pagevec usage.
>
> Further in history, before commit 408e82b7 ("mm: munlock use follow_page"),
> munlock_vma_pages_range() was just a wrapper around __mlock_vma_pages_range
> which performed both mlock and munlock depending on a flag. However, before
> ba470de4 ("mmap: handle mlocked pages during map, remap, unmap") the function
> handled only mlock, not munlock. The lru_add_drain call thus comes from the
> implementation in commit b291f000 ("mlock: mlocked pages are unevictable" and
> was intended only for mlocking, not munlocking. The original intention of
> draining the LRU pagevec at mlock time was to ensure the pages were on the LRU
> before the lock operation so that they could be placed on the unevictable list
> immediately. There is very little motivation to do the same in the munlock path
> this, particularly for every single page.
>
> This patch therefore removes the call completely. After removing the call, a
> 10% speedup was measured for munlock() of a 56GB large memory area with THP
> disabled.
>
> Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
> Reviewed-by: Jorn Engel <joern@logfs.org>
Acked-by: Mel Gorman <mgorman@suse.de>
--
Mel Gorman
SUSE Labs
--
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>
next prev parent reply other threads:[~2013-08-19 15:03 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-19 12:23 [PATCH v2 0/7] Improving munlock() performance for large non-THP areas Vlastimil Babka
2013-08-19 12:23 ` [PATCH v2 1/7] mm: putback_lru_page: remove unnecessary call to page_lru_base_type() Vlastimil Babka
2013-08-19 14:48 ` Mel Gorman
2013-08-19 12:23 ` [PATCH v2 2/7] mm: munlock: remove unnecessary call to lru_add_drain() Vlastimil Babka
2013-08-19 14:48 ` Mel Gorman [this message]
2013-08-19 12:23 ` [PATCH v2 3/7] mm: munlock: batch non-THP page isolation and munlock+putback using pagevec Vlastimil Babka
2013-08-19 14:58 ` Mel Gorman
2013-08-19 22:38 ` Andrew Morton
2013-08-22 11:13 ` Vlastimil Babka
2013-08-19 12:23 ` [PATCH v2 4/7] mm: munlock: batch NR_MLOCK zone state updates Vlastimil Babka
2013-08-19 15:01 ` Mel Gorman
2013-08-19 12:23 ` [PATCH v2 5/7] mm: munlock: bypass per-cpu pvec for putback_lru_page Vlastimil Babka
2013-08-19 15:05 ` Mel Gorman
2013-08-19 22:45 ` Andrew Morton
2013-08-22 11:16 ` Vlastimil Babka
2013-08-19 12:23 ` [PATCH v2 6/7] mm: munlock: remove redundant get_page/put_page pair on the fast path Vlastimil Babka
2013-08-19 15:07 ` Mel Gorman
2013-08-19 12:23 ` [PATCH v2 7/7] mm: munlock: manual pte walk in fast path instead of follow_page_mask() Vlastimil Babka
2013-08-19 22:47 ` Andrew Morton
2013-08-22 11:18 ` Vlastimil Babka
2013-08-27 22:24 ` Andrew Morton
2013-08-29 13:02 ` Vlastimil Babka
2013-08-19 22:48 ` [PATCH v2 0/7] Improving munlock() performance for large non-THP areas Andrew Morton
2013-08-22 11:21 ` Vlastimil Babka
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=20130819144853.GB23002@suse.de \
--to=mgorman@suse.de \
--cc=akpm@linux-foundation.org \
--cc=hannes@cmpxchg.org \
--cc=hughd@google.com \
--cc=joern@logfs.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.cz \
--cc=riel@redhat.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.