All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Nazarewicz <mina86@mina86.com>
To: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: "Andrew Morton" <akpm@linux-foundation.org>,
	"Gioh Kim" <gioh.kim@lge.com>,
	"Laura Abbott" <lauraa@codeaurora.org>,
	"Marek Szyprowski" <m.szyprowski@samsung.com>,
	"Alexander Viro" <viro@zeniv.linux.org.uk>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	이건호 <gunho.lee@lge.com>, "Gi-Oh Kim" <gurugio@gmail.com>
Subject: Re: [PATCH] [RFC] CMA: clear buffer-head lru before page migration
Date: Mon, 14 Jul 2014 17:25:41 +0200	[thread overview]
Message-ID: <xa1t4mykarnu.fsf@mina86.com> (raw)
In-Reply-To: <20140714070225.GE11317@js1304-P5Q-DELUXE>

On Mon, Jul 14 2014, Joonsoo Kim <iamjoonsoo.kim@lge.com> wrote:
> On Tue, Jul 08, 2014 at 06:46:31PM +0200, Michal Nazarewicz wrote:
>> This seems reasonable, except I think [invalidate_bh_lrus()] should
>> go after start_isolate_page_range call because otherwise there's no
>> guarantee that someone won't grab those pages back.
>> 
>> Also to avoid the #ifdef perhaps we want this as well:
>
> I think that we just want to remove ifdef CONFIG_CMA on above code
> snippet, because invalidate_bh_lrus() would also help user of
> alloc_contig_range() with MIGRATE_MOVABLE.

Sounds good to me.

>> The purpose is to get free non-buddy pages (so pages on PCP lists for
>> instance) back onto the buddy list.  It's safe to move those calls above
>> the call to __alloc_contig_migrate_range, but I don't think it will
>> change anything (except of course the fact that if migration fails,
>> we'll do the draining for nothing).

> At a glance, we don't need that drain_all_pages(), because
> drain_all_pages() is also called by set_migratetype_isolate() after
> changing migratetype.

You are likely correct.

> And, it is better to move up lru_add_drain_all() to ahead of
> __alloc_contig_migrate_range(), because some pages could be skipped
> to migrate due to this lru page caching mechanism.

Again, sounds good to me.

-- 
Best regards,                                         _     _
.o. | Liege of Serenely Enlightened Majesty of      o' \,=./ `o
..o | Computer Science,  Michał “mina86” Nazarewicz    (o o)
ooo +--<mpn@google.com>--<xmpp:mina86@jabber.org>--ooO--(_)--Ooo--

  reply	other threads:[~2014-07-14 15:25 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-04  8:25 [PATCH] [RFC] CMA: clear buffer-head lru before page migration Gioh Kim
2014-07-07 22:52 ` Andrew Morton
2014-07-08  4:44   ` Gioh Kim
2014-07-08  4:48     ` Andrew Morton
2014-07-08 16:46   ` Michal Nazarewicz
2014-07-08 16:46     ` Michal Nazarewicz
2014-07-14  7:02     ` Joonsoo Kim
2014-07-14  7:02       ` Joonsoo Kim
2014-07-14 15:25       ` Michal Nazarewicz [this message]
2014-07-14 20:37       ` Andrew Morton
2014-07-15  6:25         ` Gioh Kim
2014-07-15  6:25           ` Gioh 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=xa1t4mykarnu.fsf@mina86.com \
    --to=mina86@mina86.com \
    --cc=akpm@linux-foundation.org \
    --cc=gioh.kim@lge.com \
    --cc=gunho.lee@lge.com \
    --cc=gurugio@gmail.com \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=lauraa@codeaurora.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=viro@zeniv.linux.org.uk \
    /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.