From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:57156) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TBm0z-0001RT-LR for qemu-devel@nongnu.org; Wed, 12 Sep 2012 08:25:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TBm0p-0008Fe-9d for qemu-devel@nongnu.org; Wed, 12 Sep 2012 08:25:57 -0400 Received: from cantor2.suse.de ([195.135.220.15]:42615 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TBm0o-0008FE-Va for qemu-devel@nongnu.org; Wed, 12 Sep 2012 08:25:47 -0400 Date: Wed, 12 Sep 2012 13:25:41 +0100 From: Mel Gorman Message-ID: <20120912122541.GO11266@suse.de> References: <5034A18B.5040408@redhat.com> <20120822124032.GA12647@alpha.arachsys.com> <5034D437.8070106@redhat.com> <20120822144150.GA1400@alpha.arachsys.com> <5034F8F4.3080301@redhat.com> <20120825174550.GA8619@alpha.arachsys.com> <50391564.30401@redhat.com> <20120826105803.GA377@alpha.arachsys.com> <20120906092039.GA19234@alpha.arachsys.com> <20120912105659.GA23818@alpha.arachsys.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <20120912105659.GA23818@alpha.arachsys.com> Subject: Re: [Qemu-devel] Windows VM slow boot List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Richard Davies Cc: kvm@vger.kernel.org, qemu-devel@nongnu.org, linux-mm@kvack.org, Avi Kivity , Shaohua Li 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 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 Acked-by: Mel Gorman Acked-by: Minchan Kim Signed-off-by: Andrew Morton --- 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;