All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joonsoo Kim <iamjoonsoo.kim@lge.com>
To: Rafael Aquini <aquini@redhat.com>
Cc: Mel Gorman <mgorman@suse.de>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [QUESTION] balloon page isolation needs LRU lock?
Date: Mon, 9 Dec 2013 17:47:20 +0900	[thread overview]
Message-ID: <20131209084720.GB27201@lge.com> (raw)
In-Reply-To: <20131206122142.GC26883@localhost.localdomain>

On Fri, Dec 06, 2013 at 10:21:43AM -0200, Rafael Aquini wrote:
> On Fri, Dec 06, 2013 at 05:53:31PM +0900, Joonsoo Kim wrote:
> > Hello, Rafael.
> > 
> > I looked at some compaction code and found that some oddity about
> > balloon compaction. In isolate_migratepages_range(), if we meet
> > !PageLRU(), we check whether this page is for balloon compaction.
> > In this case, code needs locked. Is the lock really needed? I can't find
> > any relationship between balloon compaction and LRU lock.
> > 
> > Second question is that in above case if we don't hold a lock, we
> > skip this page. I guess that if we meet balloon page repeatedly, there
> > is no change to run isolation. Am I missing?
> > 
> > Please let me know what I am missing.
> > 
> > Thanks in advance.
> 
> Howdy Joonsoo, thanks for your question.
> 
> The major reason I left the 'locked' case in place when isolating balloon pages
> was to keep consistency with the other isolation cases. Among all page types we
> isolate for compaction balloon pages are an exception as, you noticed, they're
> not on LRU lists. So, we (specially) fake balloon pages as LRU to isolate/compact them, 
> withouth having to sort to drastic surgeries into kernel code to implement
> exception cases for isolating/compacting balloon pages.
> 
> As others pages we isolate for compaction are isolated while holding the
> zone->lru_lock, I left the same condition placed for balloon pages as a
> safeguard for consistency. If we hit a balloon page while scanning page blocks
> and we do not have the lru lock held, then the balloon page will be treated 
> by the scanning mechanism just as what it is: a !PageLRU() case, and life will
> go on as described by the algorithm.
> 
> OTOH, there's no direct relationship between the balloon page and the LRU lock,
> other than this consistency one I aforementioned. I've never seen any major
> trouble on letting the lock requirement in place during my tests on workloads
> that mix balloon pages and compaction. However, if you're seeing any trouble and
> that lru lock requirement is acting as an overkill or playing a bad role on your
> tests, you can get rid of it easily, IMHO.

Hello, Rafael.

Thanks for nice explanation.
Now I totally understand what it means and why it does.

Thanks!

--
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: Joonsoo Kim <iamjoonsoo.kim@lge.com>
To: Rafael Aquini <aquini@redhat.com>
Cc: Mel Gorman <mgorman@suse.de>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [QUESTION] balloon page isolation needs LRU lock?
Date: Mon, 9 Dec 2013 17:47:20 +0900	[thread overview]
Message-ID: <20131209084720.GB27201@lge.com> (raw)
In-Reply-To: <20131206122142.GC26883@localhost.localdomain>

On Fri, Dec 06, 2013 at 10:21:43AM -0200, Rafael Aquini wrote:
> On Fri, Dec 06, 2013 at 05:53:31PM +0900, Joonsoo Kim wrote:
> > Hello, Rafael.
> > 
> > I looked at some compaction code and found that some oddity about
> > balloon compaction. In isolate_migratepages_range(), if we meet
> > !PageLRU(), we check whether this page is for balloon compaction.
> > In this case, code needs locked. Is the lock really needed? I can't find
> > any relationship between balloon compaction and LRU lock.
> > 
> > Second question is that in above case if we don't hold a lock, we
> > skip this page. I guess that if we meet balloon page repeatedly, there
> > is no change to run isolation. Am I missing?
> > 
> > Please let me know what I am missing.
> > 
> > Thanks in advance.
> 
> Howdy Joonsoo, thanks for your question.
> 
> The major reason I left the 'locked' case in place when isolating balloon pages
> was to keep consistency with the other isolation cases. Among all page types we
> isolate for compaction balloon pages are an exception as, you noticed, they're
> not on LRU lists. So, we (specially) fake balloon pages as LRU to isolate/compact them, 
> withouth having to sort to drastic surgeries into kernel code to implement
> exception cases for isolating/compacting balloon pages.
> 
> As others pages we isolate for compaction are isolated while holding the
> zone->lru_lock, I left the same condition placed for balloon pages as a
> safeguard for consistency. If we hit a balloon page while scanning page blocks
> and we do not have the lru lock held, then the balloon page will be treated 
> by the scanning mechanism just as what it is: a !PageLRU() case, and life will
> go on as described by the algorithm.
> 
> OTOH, there's no direct relationship between the balloon page and the LRU lock,
> other than this consistency one I aforementioned. I've never seen any major
> trouble on letting the lock requirement in place during my tests on workloads
> that mix balloon pages and compaction. However, if you're seeing any trouble and
> that lru lock requirement is acting as an overkill or playing a bad role on your
> tests, you can get rid of it easily, IMHO.

Hello, Rafael.

Thanks for nice explanation.
Now I totally understand what it means and why it does.

Thanks!


  reply	other threads:[~2013-12-09  8:44 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-06  8:53 [QUESTION] balloon page isolation needs LRU lock? Joonsoo Kim
2013-12-06  8:53 ` Joonsoo Kim
2013-12-06 12:21 ` Rafael Aquini
2013-12-06 12:21   ` Rafael Aquini
2013-12-09  8:47   ` Joonsoo Kim [this message]
2013-12-09  8:47     ` Joonsoo 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=20131209084720.GB27201@lge.com \
    --to=iamjoonsoo.kim@lge.com \
    --cc=akpm@linux-foundation.org \
    --cc=aquini@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@suse.de \
    /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.