From: Vlastimil Babka <vbabka@suse.cz>
To: Konstantin Khlebnikov <koct9i@gmail.com>, linux-mm@kvack.org
Subject: Re: [PATCH RFC v0 0/6] mm: proof-of-concept memory compaction without isolation
Date: Mon, 15 Jun 2015 11:52:27 +0200 [thread overview]
Message-ID: <557EA05B.3040405@suse.cz> (raw)
In-Reply-To: <20150615073926.18112.59207.stgit@zurg>
On 06/15/2015 09:50 AM, Konstantin Khlebnikov wrote:
> This is incomplete implementation of non-isolating memory migration and
> compaction. It's alive!
>
> The main reason -- it can preserve lru order during compaction.
That's nice, and there's also another benefit - no lru_lock taken during
migration scanner.
So I think it's worth pursuing. But after brief checking, I'm not sure
it can work as it is (but maybe I just overlooked something). What
prevents somebody else to isolate the old page from the lru while you
are migrating it? Especially in Patch 6, it appears that a PageLRU() is
tested without any lock and only then insert_lru_page() takes the
lru_lock to do something. This seems racy to me.
>
> Also it makes implementation of migration for various types of pages: zram,
> balloon, ptes, kernel stacks [ Why not? I've already migrated them accidentally
> and kernel have crashed in very funny places ] much easier: owner just have to
> set page->mappingw with valid method a_ops->migratepage.
>
> ---
>
> Konstantin Khlebnikov (6):
> pagevec: segmented page vectors
> mm/migrate: move putback of old page out of unmap_and_move
> mm/cma: repalce reclaim_clean_pages_from_list with try_to_reclaim_page
> mm/migrate: page migration without page isolation
> mm/compaction: use migration without isolation
> mm/migrate: preserve lru order if possible
>
>
> include/linux/migrate.h | 4 +
> include/linux/mm.h | 1
> include/linux/pagevec.h | 48 ++++++++-
> include/trace/events/compaction.h | 12 +-
> mm/compaction.c | 205 +++++++++++++++++++++----------------
> mm/filemap.c | 20 ++++
> mm/internal.h | 12 +-
> mm/migrate.c | 141 +++++++++++++++++++++----
> mm/page_alloc.c | 35 ++++--
> mm/swap.c | 69 ++++++++++++
> mm/vmscan.c | 42 +-------
> 11 files changed, 410 insertions(+), 179 deletions(-)
>
> --
> 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>
>
--
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>
prev parent reply other threads:[~2015-06-15 9:52 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-15 7:50 Konstantin Khlebnikov
2015-06-15 7:51 ` [PATCH RFC v0 1/6] pagevec: segmented page vectors Konstantin Khlebnikov
2015-06-15 7:51 ` [PATCH RFC v0 2/6] mm/migrate: move putback of old page out of unmap_and_move Konstantin Khlebnikov
2015-06-15 7:51 ` [PATCH RFC v0 3/6] mm/cma: repalce reclaim_clean_pages_from_list with try_to_reclaim_page Konstantin Khlebnikov
2015-06-15 7:51 ` [PATCH RFC v0 4/6] mm/migrate: page migration without page isolation Konstantin Khlebnikov
2015-06-15 7:51 ` [PATCH RFC v0 5/6] mm/compaction: use migration without isolation Konstantin Khlebnikov
2015-06-15 7:51 ` [PATCH RFC v0 6/6] mm/migrate: preserve lru order if possible Konstantin Khlebnikov
2015-06-15 9:52 ` Vlastimil Babka [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=557EA05B.3040405@suse.cz \
--to=vbabka@suse.cz \
--cc=koct9i@gmail.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