From: Minchan Kim <minchan@kernel.org>
To: Chulmin Kim <cmlaika.kim@samsung.com>
Cc: linux-mm@kvack.org
Subject: Re: [PATCH v2 01/18] mm: use put_page to free page instead of putback_lru_page
Date: Tue, 22 Mar 2016 08:56:04 +0900 [thread overview]
Message-ID: <20160321235604.GB27197@bbox> (raw)
In-Reply-To: <56EF9F27.9060400@samsung.com>
On Mon, Mar 21, 2016 at 04:13:43PM +0900, Chulmin Kim wrote:
> On 2016년 03월 21일 15:30, Minchan Kim wrote:
> >Procedure of page migration is as follows:
> >
> >First of all, it should isolate a page from LRU and try to
> >migrate the page. If it is successful, it releases the page
> >for freeing. Otherwise, it should put the page back to LRU
> >list.
> >
> >For LRU pages, we have used putback_lru_page for both freeing
> >and putback to LRU list. It's okay because put_page is aware of
> >LRU list so if it releases last refcount of the page, it removes
> >the page from LRU list. However, It makes unnecessary operations
> >(e.g., lru_cache_add, pagevec and flags operations. It would be
> >not significant but no worth to do) and harder to support new
> >non-lru page migration because put_page isn't aware of non-lru
> >page's data structure.
> >
> >To solve the problem, we can add new hook in put_page with
> >PageMovable flags check but it can increase overhead in
> >hot path and needs new locking scheme to stabilize the flag check
> >with put_page.
> >
> >So, this patch cleans it up to divide two semantic(ie, put and putback).
> >If migration is successful, use put_page instead of putback_lru_page and
> >use putback_lru_page only on failure. That makes code more readable
> >and doesn't add overhead in put_page.
> >
> >Comment from Vlastimil
> >"Yeah, and compaction (perhaps also other migration users) has to drain
> >the lru pvec... Getting rid of this stuff is worth even by itself."
> >
> >Cc: Mel Gorman <mgorman@suse.de>
> >Cc: Hugh Dickins <hughd@google.com>
> >Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
> >Acked-by: Vlastimil Babka <vbabka@suse.cz>
> >Signed-off-by: Minchan Kim <minchan@kernel.org>
> >---
> > mm/migrate.c | 50 +++++++++++++++++++++++++++++++-------------------
> > 1 file changed, 31 insertions(+), 19 deletions(-)
> >
> >diff --git a/mm/migrate.c b/mm/migrate.c
> >index 6c822a7b27e0..b65c84267ce0 100644
> >--- a/mm/migrate.c
> >+++ b/mm/migrate.c
> >@@ -913,6 +913,14 @@ static int __unmap_and_move(struct page *page, struct page *newpage,
> > put_anon_vma(anon_vma);
> > unlock_page(page);
> > out:
> >+ /* If migration is scucessful, move newpage to right list */
>
> A minor comment fix :)
> + /* If migration is successful, move newpage to right list */
Hello Chulmin,
Fixed the typo.
Thanks for the review!
--
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:[~2016-03-21 23:54 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-21 6:30 [PATCH v2 00/18] Support non-lru page migration Minchan Kim
2016-03-21 6:30 ` [PATCH v2 01/18] mm: use put_page to free page instead of putback_lru_page Minchan Kim
2016-03-21 7:13 ` Chulmin Kim
2016-03-21 23:56 ` Minchan Kim [this message]
2016-03-21 6:30 ` [PATCH v2 02/18] zsmalloc: use first_page rather than page Minchan Kim
2016-03-21 6:30 ` [PATCH v2 03/18] zsmalloc: clean up many BUG_ON Minchan Kim
2016-03-21 6:30 ` [PATCH v2 04/18] zsmalloc: reordering function parameter Minchan Kim
2016-03-21 6:30 ` [PATCH v2 05/18] zsmalloc: remove unused pool param in obj_free Minchan Kim
2016-03-21 6:30 ` [PATCH v2 06/18] zsmalloc: keep max_object in size_class Minchan Kim
2016-03-21 6:30 ` [PATCH v2 07/18] zsmalloc: squeeze inuse into page->mapping Minchan Kim
2016-03-21 6:30 ` [PATCH v2 08/18] zsmalloc: squeeze freelist " Minchan Kim
2016-03-21 6:30 ` [PATCH v2 09/18] zsmalloc: move struct zs_meta from mapping to freelist Minchan Kim
2016-03-21 6:30 ` [PATCH v2 10/18] zsmalloc: factor page chain functionality out Minchan Kim
2016-03-21 6:31 ` [PATCH v2 11/18] zsmalloc: separate free_zspage from putback_zspage Minchan Kim
2016-03-21 6:31 ` [PATCH v2 12/18] zsmalloc: zs_compact refactoring Minchan Kim
2016-03-21 6:31 ` [PATCH v2 13/18] mm/compaction: support non-lru movable page migration Minchan Kim
2016-03-22 5:50 ` Joonsoo Kim
2016-03-22 14:55 ` Minchan Kim
2016-03-23 5:05 ` Joonsoo Kim
2016-03-24 5:00 ` Minchan Kim
2016-03-21 6:31 ` [PATCH v2 14/18] mm/balloon: use general movable page feature into balloon Minchan Kim
2016-03-21 8:29 ` kbuild test robot
2016-03-22 2:19 ` Minchan Kim
2016-03-21 6:31 ` [PATCH v2 15/18] zsmalloc: migrate head page of zspage Minchan Kim
2016-03-21 6:31 ` [PATCH v2 16/18] zsmalloc: use single linked list for page chain Minchan Kim
2016-03-21 6:31 ` [PATCH v2 17/18] zsmalloc: migrate tail pages in zspage Minchan Kim
2016-03-21 9:48 ` [PATCH] zsmalloc: fix semicolon.cocci warnings kbuild test robot
2016-03-22 2:22 ` Minchan Kim
2016-03-21 9:48 ` [PATCH v2 17/18] zsmalloc: migrate tail pages in zspage kbuild test robot
2016-03-21 6:31 ` [PATCH v2 18/18] zram: use __GFP_MOVABLE for memory allocation Minchan Kim
2016-03-28 5:08 ` [PATCH v2 00/18] Support non-lru page migration Minchan Kim
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=20160321235604.GB27197@bbox \
--to=minchan@kernel.org \
--cc=cmlaika.kim@samsung.com \
--cc=linux-mm@kvack.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).