From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751778Ab2KTGAW (ORCPT ); Tue, 20 Nov 2012 01:00:22 -0500 Received: from mail-ee0-f46.google.com ([74.125.83.46]:57698 "EHLO mail-ee0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751015Ab2KTGAU (ORCPT ); Tue, 20 Nov 2012 01:00:20 -0500 Date: Tue, 20 Nov 2012 07:00:14 +0100 From: Ingo Molnar To: David Rientjes Cc: Mel Gorman , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Peter Zijlstra , Paul Turner , Lee Schermerhorn , Christoph Lameter , Rik van Riel , Andrew Morton , Andrea Arcangeli , Linus Torvalds , Thomas Gleixner , Johannes Weiner , Hugh Dickins Subject: Re: [PATCH 00/27] Latest numa/core release, v16 Message-ID: <20121120060014.GA14065@gmail.com> References: <1353291284-2998-1-git-send-email-mingo@kernel.org> <20121119162909.GL8218@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * David Rientjes wrote: > > numa/core at ec05a2311c35 ("Merge branch 'sched/urgent' into > > sched/core") had an average throughput of 136918.34 > > SPECjbb2005 bops, which is a 6.3% regression. > > perftop during the run on numa/core at 01aa90068b12 ("sched: > Use the best-buddy 'ideal cpu' in balancing decisions"): > > 15.99% [kernel] [k] page_fault > 4.05% [kernel] [k] getnstimeofday > 3.96% [kernel] [k] _raw_spin_lock > 3.20% [kernel] [k] rcu_check_callbacks > 2.93% [kernel] [k] generic_smp_call_function_interrupt > 2.90% [kernel] [k] __do_page_fault > 2.82% [kernel] [k] ktime_get Thanks for testing, that's very interesting - could you tell me more about exactly what kind of hardware this is? I'll try to find a similar system and reproduce the performance regression. (A wild guess would be an older 4x Opteron system, 83xx series or so?) Also, the profile looks weird to me. Here is how perf top looks like on my system during a similarly configured, "healthy" SPECjbb run: 91.29% perf-6687.map [.] 0x00007fffed1e8f21 4.81% libjvm.so [.] 0x00000000007004a0 0.93% [vdso] [.] 0x00007ffff7ffe60c 0.72% [kernel] [k] do_raw_spin_lock 0.36% [kernel] [k] generic_smp_call_function_interrupt 0.10% [kernel] [k] format_decode 0.07% [kernel] [k] rcu_check_callbacks 0.07% [kernel] [k] apic_timer_interrupt 0.07% [kernel] [k] call_function_interrupt 0.06% libc-2.15.so [.] __strcmp_sse42 0.06% [kernel] [k] irqtime_account_irq 0.06% perf [.] 0x000000000004bb7c 0.05% [kernel] [k] x86_pmu_disable_all 0.04% libc-2.15.so [.] __memcpy_ssse3 0.04% [kernel] [k] ktime_get 0.04% [kernel] [k] account_group_user_time 0.03% [kernel] [k] vbin_printf and that is what SPECjbb does: it spends 97% of its time in Java code - yet there's no Java overhead visible in your profile - how is that possible? Could you try a newer perf on that box: cd tools/perf/ make -j install to make sure perf picks up the Java symbols as well (or at least includes them as a summary, as in the profile above). Note that no page fault overhead is visible in my profile. Thanks, Ingo