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;
WARNING: multiple messages have this Message-ID (diff)
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>
WARNING: multiple messages have this Message-ID (diff)
From: Mel Gorman <mgorman@suse.de>
To: Richard Davies <richard@arachsys.com>
Cc: kvm@vger.kernel.org, qemu-devel@nongnu.org, linux-mm@kvack.org,
Avi Kivity <avi@redhat.com>, Shaohua Li <shli@kernel.org>
Subject: Re: [Qemu-devel] 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;
next prev parent reply other threads:[~2012-09-12 12:25 UTC|newest]
Thread overview: 101+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-16 10:47 Windows slow boot: contractor wanted Richard Davies
2012-08-16 10:47 ` [Qemu-devel] " Richard Davies
2012-08-16 11:39 ` Avi Kivity
2012-08-16 11:39 ` [Qemu-devel] " Avi Kivity
2012-08-17 12:36 ` Richard Davies
2012-08-17 12:36 ` [Qemu-devel] " Richard Davies
2012-08-17 13:02 ` Robert Vineyard
2012-08-17 13:02 ` [Qemu-devel] " Robert Vineyard
2012-08-18 14:44 ` Richard Davies
2012-08-18 14:44 ` [Qemu-devel] " Richard Davies
2012-08-19 5:02 ` Brian Jackson
2012-08-19 5:02 ` [Qemu-devel] " Brian Jackson
2012-08-20 8:16 ` Richard Davies
2012-08-20 8:16 ` [Qemu-devel] " Richard Davies
2012-08-19 8:40 ` Avi Kivity
2012-08-19 8:40 ` [Qemu-devel] " Avi Kivity
2012-08-19 8:51 ` Richard Davies
2012-08-19 8:51 ` [Qemu-devel] " Richard Davies
2012-08-19 14:04 ` Avi Kivity
2012-08-19 14:04 ` [Qemu-devel] " Avi Kivity
2012-08-20 13:56 ` Richard Davies
2012-08-20 13:56 ` [Qemu-devel] " Richard Davies
2012-08-21 9:00 ` Avi Kivity
2012-08-21 9:00 ` [Qemu-devel] " Avi Kivity
2012-08-21 15:21 ` Richard Davies
2012-08-21 15:21 ` [Qemu-devel] " Richard Davies
2012-08-21 15:39 ` Troy Benjegerdes
2012-08-21 15:39 ` Troy Benjegerdes
2012-08-22 9:08 ` Avi Kivity
2012-08-22 9:08 ` [Qemu-devel] " Avi Kivity
2012-08-22 12:40 ` Richard Davies
2012-08-22 12:40 ` [Qemu-devel] " Richard Davies
2012-08-22 12:44 ` Avi Kivity
2012-08-22 12:44 ` [Qemu-devel] " Avi Kivity
2012-08-22 14:41 ` Richard Davies
2012-08-22 14:41 ` [Qemu-devel] " Richard Davies
2012-08-22 14:53 ` Avi Kivity
2012-08-22 14:53 ` [Qemu-devel] " Avi Kivity
2012-08-22 15:26 ` Richard Davies
2012-08-22 15:26 ` [Qemu-devel] " Richard Davies
2012-08-22 17:22 ` Troy Benjegerdes
2012-08-22 17:22 ` Troy Benjegerdes
2012-08-25 17:51 ` Richard Davies
2012-08-25 17:51 ` Richard Davies
2012-08-22 15:21 ` Rik van Riel
2012-08-22 15:21 ` [Qemu-devel] " Rik van Riel
2012-08-22 15:34 ` Richard Davies
2012-08-22 15:34 ` [Qemu-devel] " Richard Davies
2012-08-25 17:45 ` Richard Davies
2012-08-25 17:45 ` [Qemu-devel] " Richard Davies
2012-08-25 18:11 ` Rik van Riel
2012-08-25 18:11 ` [Qemu-devel] " Rik van Riel
2012-08-26 10:58 ` Richard Davies
2012-08-26 10:58 ` [Qemu-devel] " Richard Davies
2012-09-06 9:20 ` Richard Davies
2012-09-06 9:20 ` [Qemu-devel] " Richard Davies
2012-09-12 10:56 ` Windows VM slow boot Richard Davies
2012-09-12 10:56 ` [Qemu-devel] " Richard Davies
2012-09-12 10:56 ` Richard Davies
2012-09-12 12:25 ` Mel Gorman [this message]
2012-09-12 12:25 ` [Qemu-devel] " Mel Gorman
2012-09-12 12:25 ` Mel Gorman
2012-09-12 16:46 ` Richard Davies
2012-09-12 16:46 ` [Qemu-devel] " Richard Davies
2012-09-12 16:46 ` Richard Davies
2012-09-13 9:50 ` Mel Gorman
2012-09-13 9:50 ` [Qemu-devel] " Mel Gorman
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:47 ` [Qemu-devel] " Rik van Riel
2012-09-13 19:47 ` 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:48 ` [Qemu-devel] " Rik van Riel
2012-09-13 19:48 ` Rik van Riel
2012-09-13 19:54 ` [PATCH -v2 " Rik van Riel
2012-09-13 19:54 ` [Qemu-devel] " Rik van Riel
2012-09-13 19:54 ` Rik van Riel
2012-09-15 15:55 ` Richard Davies
2012-09-15 15:55 ` [Qemu-devel] " Richard Davies
2012-09-15 15:55 ` Richard Davies
2012-09-16 19:12 ` Richard Davies
2012-09-16 19:12 ` [Qemu-devel] " Richard Davies
2012-09-17 12:26 ` Mel Gorman
2012-09-17 12:26 ` [Qemu-devel] " Mel Gorman
2012-09-18 8:14 ` Richard Davies
2012-09-18 8:14 ` [Qemu-devel] " Richard Davies
2012-09-18 11:21 ` Mel Gorman
2012-09-18 11:21 ` [Qemu-devel] " Mel Gorman
2012-09-18 11:21 ` Mel Gorman
2012-09-18 17:58 ` Richard Davies
2012-09-18 17:58 ` [Qemu-devel] " Richard Davies
2012-09-17 13:50 ` Rik van Riel
2012-09-17 13:50 ` [Qemu-devel] " Rik van Riel
2012-09-17 14:07 ` Mel Gorman
2012-09-17 14:07 ` [Qemu-devel] " Mel Gorman
2012-09-17 14:07 ` Mel Gorman
2012-08-16 14:10 ` Windows slow boot: contractor wanted Benoît Canet
2012-08-16 14:10 ` [Qemu-devel] " Benoît Canet
2012-08-16 15:53 ` Troy Benjegerdes
2012-09-18 15:12 ` Windows slow boot Michael Tokarev
2012-09-18 15:12 ` [Qemu-devel] " Michael Tokarev
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 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.