linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Mel Gorman <mgorman@suse.de>
To: Richard Davies <richard@arachsys.com>
Cc: Rik van Riel <riel@redhat.com>, Avi Kivity <avi@redhat.com>,
	Shaohua Li <shli@kernel.org>,
	qemu-devel@nongnu.org, kvm@vger.kernel.org, linux-mm@kvack.org
Subject: Re: Windows VM slow boot
Date: Wed, 12 Sep 2012 13:25:41 +0100	[thread overview]
Message-ID: <20120912122541.GO11266@suse.de> (raw)
In-Reply-To: <20120912105659.GA23818@alpha.arachsys.com>

On Wed, Sep 12, 2012 at 11:56:59AM +0100, Richard Davies wrote:
> [ adding linux-mm - previously at http://marc.info/?t=134511509400003 ]
> 
> Hi Rik,
> 

I'm not Rik but hi anyway.

> Since qemu-kvm 1.2.0 and Linux 3.6.0-rc5 came out, I thought that I would
> retest with these.
> 

Ok. 3.6.0-rc5 contains [c67fe375: mm: compaction: Abort async compaction
if locks are contended or taking too long] that should have helped mitigate
some of the lock contention problem but not all of it as we'll see later.

> The typical symptom now appears to be that the Windows VMs boot reasonably
> fast,

I see that this is an old-ish bug but I did not read the full history.
Is it now booting faster than 3.5.0 was? I'm asking because I'm
interested to see if commit c67fe375 helped your particular case.

> but then there is high CPU use and load for many minutes afterwards -
> the high CPU use is both for the qemu-kvm processes themselves and also for
> % sys.
> 

Ok, I cannot comment on the userspace portion of things but the kernel
portion still indicates that there is a high percentage of time on what
appears to be lock contention.

> I attach a perf report which seems to show that the high CPU use is in the
> memory manager.
> 

A follow-on from commit c67fe375 was the following patch (author cc'd)
which addresses lock contention in isolate_migratepages_range where your
perf report indicates that we're spending 95% of the time. Would you be
willing to test it please?

---8<---
From: Shaohua Li <shli@kernel.org>
Subject: mm: compaction: check lock contention first before taking lock

isolate_migratepages_range will take zone->lru_lock first and check if the
lock is contented, if yes, it will release the lock.  This isn't
efficient.  If the lock is truly contented, a lock/unlock pair will
increase the lock contention.  We'd better check if the lock is contended
first.  compact_trylock_irqsave perfectly meets the requirement.

Signed-off-by: Shaohua Li <shli@fusionio.com>
Acked-by: Mel Gorman <mgorman@suse.de>
Acked-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 mm/compaction.c |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff -puN mm/compaction.c~mm-compaction-check-lock-contention-first-before-taking-lock mm/compaction.c
--- a/mm/compaction.c~mm-compaction-check-lock-contention-first-before-taking-lock
+++ a/mm/compaction.c
@@ -349,8 +349,9 @@ isolate_migratepages_range(struct zone *
 
 	/* Time to isolate some pages for migration */
 	cond_resched();
-	spin_lock_irqsave(&zone->lru_lock, flags);
-	locked = true;
+	locked = compact_trylock_irqsave(&zone->lru_lock, &flags, cc);
+	if (!locked)
+		return 0;
 	for (; low_pfn < end_pfn; low_pfn++) {
 		struct page *page;
 

--
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>

  reply	other threads:[~2012-09-12 12:25 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20120821152107.GA16363@alpha.arachsys.com>
     [not found] ` <5034A18B.5040408@redhat.com>
     [not found]   ` <20120822124032.GA12647@alpha.arachsys.com>
     [not found]     ` <5034D437.8070106@redhat.com>
     [not found]       ` <20120822144150.GA1400@alpha.arachsys.com>
     [not found]         ` <5034F8F4.3080301@redhat.com>
     [not found]           ` <20120825174550.GA8619@alpha.arachsys.com>
     [not found]             ` <50391564.30401@redhat.com>
     [not found]               ` <20120826105803.GA377@alpha.arachsys.com>
     [not found]                 ` <20120906092039.GA19234@alpha.arachsys.com>
2012-09-12 10:56                   ` Windows VM slow boot Richard Davies
2012-09-12 12:25                     ` Mel Gorman [this message]
2012-09-12 16:46                       ` Richard Davies
2012-09-13  9:50                         ` Mel Gorman
2012-09-13 19:47                         ` [PATCH 1/2] Revert "mm: have order > 0 compaction start near a pageblock with free pages" Rik van Riel
2012-09-13 19:48                         ` [PATCH 2/2] make the compaction "skip ahead" logic robust Rik van Riel
2012-09-13 19:54                           ` [PATCH -v2 " Rik van Riel
2012-09-15 15:55                             ` Richard Davies
2012-09-16 19:12                               ` Richard Davies
2012-09-17 12:26                               ` Mel Gorman
2012-09-18  8:14                                 ` Richard Davies
2012-09-18 11:21                                   ` Mel Gorman
2012-09-18 17:58                                     ` Richard Davies
2012-09-17 13:50                               ` Rik van Riel
2012-09-17 14:07                                 ` Mel Gorman

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=20120912122541.GO11266@suse.de \
    --to=mgorman@suse.de \
    --cc=avi@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=qemu-devel@nongnu.org \
    --cc=richard@arachsys.com \
    --cc=riel@redhat.com \
    --cc=shli@kernel.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).