From patchwork Wed Sep 12 12:25:41 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mel Gorman X-Patchwork-Id: 183404 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 64B952C007A for ; Thu, 13 Sep 2012 02:12:41 +1000 (EST) Received: from localhost ([::1]:49009 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TBpYN-000868-74 for incoming@patchwork.ozlabs.org; Wed, 12 Sep 2012 12:12:39 -0400 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 Received: from relay2.suse.de (unknown [195.135.220.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx2.suse.de (Postfix) with ESMTP id A22C59D938; Wed, 12 Sep 2012 14:25:44 +0200 (CEST) Date: Wed, 12 Sep 2012 13:25:41 +0100 From: Mel Gorman To: Richard Davies 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-Disposition: inline In-Reply-To: <20120912105659.GA23818@alpha.arachsys.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4-2.6 X-Received-From: 195.135.220.15 X-Mailman-Approved-At: Wed, 12 Sep 2012 12:12:29 -0400 Cc: kvm@vger.kernel.org, qemu-devel@nongnu.org, linux-mm@kvack.org, Avi Kivity , Shaohua Li Subject: Re: [Qemu-devel] Windows VM slow boot X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org 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;