From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:60732) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TDbzE-0005lb-Uv for qemu-devel@nongnu.org; Mon, 17 Sep 2012 10:07:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TDbz8-0006rX-W7 for qemu-devel@nongnu.org; Mon, 17 Sep 2012 10:07:44 -0400 Received: from cantor2.suse.de ([195.135.220.15]:59005 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TDbz8-0006rA-MT for qemu-devel@nongnu.org; Mon, 17 Sep 2012 10:07:38 -0400 Date: Mon, 17 Sep 2012 15:07:35 +0100 From: Mel Gorman Message-ID: <20120917140735.GG11266@suse.de> References: <50391564.30401@redhat.com> <20120826105803.GA377@alpha.arachsys.com> <20120906092039.GA19234@alpha.arachsys.com> <20120912105659.GA23818@alpha.arachsys.com> <20120912122541.GO11266@suse.de> <20120912164615.GA14173@alpha.arachsys.com> <20120913154824.44cc0e28@cuia.bos.redhat.com> <20120913155450.7634148f@cuia.bos.redhat.com> <20120915155524.GA24182@alpha.arachsys.com> <50572A90.1030109@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <50572A90.1030109@redhat.com> Subject: Re: [Qemu-devel] [PATCH -v2 2/2] make the compaction "skip ahead" logic robust List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Rik van Riel Cc: Richard Davies , kvm@vger.kernel.org, qemu-devel@nongnu.org, linux-mm@kvack.org, Avi Kivity , Shaohua Li On Mon, Sep 17, 2012 at 09:50:08AM -0400, Rik van Riel wrote: > On 09/15/2012 11:55 AM, Richard Davies wrote: > >Hi Rik, Mel and Shaohua, > > > >Thank you for your latest patches. I attach my latest perf report for a slow > >boot with all of these applied. > > > >Mel asked for timings of the slow boots. It's very hard to give anything > >useful here! A normal boot would be a minute or so, and many are like that, > >but the slowest that I have seen (on 3.5.x) was several hours. Basically, I > >just test many times until I get one which is noticeably slow than normal > >and then run perf record on that one. > > > >The latest perf report for a slow boot is below. For the fast boots, most of > >the time is in clean_page_c in do_huge_pmd_anonymous_page, but for this slow > >one there is a lot of lock contention above that. > > How often do you run into slow boots, vs. fast ones? > > ># Overhead Command Shared Object Symbol > ># ........ ............... .................... .............................................. > ># > > 58.49% qemu-kvm [kernel.kallsyms] [k] _raw_spin_lock_irqsave > > | > > --- _raw_spin_lock_irqsave > > | > > |--95.07%-- compact_checklock_irqsave > > | | > > | |--70.03%-- isolate_migratepages_range > > | | compact_zone > > | | compact_zone_order > > | | try_to_compact_pages > > | | __alloc_pages_direct_compact > > | | __alloc_pages_nodemask > > Looks like it moved from isolate_freepages_block in your last > trace, to isolate_migratepages_range? > > Mel, I wonder if we have any quadratic complexity problems > in this part of the code, too? > Possibly but right now I'm focusing on the contention even though I recognise that reducing the amount of scanning implicitly reduces the amount of contention. I'm running a test at the moment with an additional patch to record the pageblock being scanned by either the free or migrate page scanner. This should be enough to both calculate the scanning efficiency and how many useless blocks are scanned to determine if your "skip" patches are behaving as expected and from there decide if the migrate scanner needs similar logic. -- Mel Gorman SUSE Labs