[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20121120114001.GR8218@suse.de>
Date: Tue, 20 Nov 2012 11:40:01 +0000
From: Mel Gorman <mgorman@...e.de>
To: Ingo Molnar <mingo@...nel.org>
Cc: linux-kernel@...r.kernel.org, linux-mm@...ck.org,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Paul Turner <pjt@...gle.com>,
Lee Schermerhorn <Lee.Schermerhorn@...com>,
Christoph Lameter <cl@...ux.com>,
Rik van Riel <riel@...hat.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Andrea Arcangeli <aarcange@...hat.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Thomas Gleixner <tglx@...utronix.de>,
Johannes Weiner <hannes@...xchg.org>,
Hugh Dickins <hughd@...gle.com>
Subject: Re: [PATCH 00/27] Latest numa/core release, v16
On Tue, Nov 20, 2012 at 11:40:53AM +0100, Ingo Molnar wrote:
>
> btw., mind sending me a fuller/longer profile than the one
> you've sent before? In particular does your system have any
> vsyscall emulation page fault overhead?
>
I can't, the results for specjbb got trashed after I moved to 3.7-rc6 and
the old run was incomplete :( I'll have to re-run for profiles. I generally
do not run with profiling enabled because it can distort results very badly.
I went back and re-examined anything else that could distort the results. I
have monitoring other than profiles enabled and the heaviest monitor by
far is reading smaps every 10 seconds to see how processes are currently
distributed between nodes and what CPU they are running on. The intention
was to be able to examine after the fact if the individual java processes
were ending up on the same nodes and scheduled properly.
However, this would impact the peak performance and affect contention on
mmap_sem every 10 seconds as it's possible for the PTE scanner and smaps
reader to contend. Care is taken to only read smaps once per process. So
for each JVM instance, it would read smaps once even though it would
examine where every thread is running. This minimises the distortion.
top is also updating every 10 seconds which will also contend on locks.
The other monitors are relatively harmless and are reading files like
/proc/vmstat, each numastat file every 10 seconds. As before, all tests
had these monitors enabled so they would all have suffered evenly.
Normally when I'm looking at a series I run both with and without monitors. I
report without monitors and use monitors to help debug and problems that
are identified. Unfortunately, time pressure is not allowing me to do that
this time.
> If yes, does the patch below change anything for you?
>
I'll check it.
Thanks.
--
Mel Gorman
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists