linux-kernel - Re: [PATCH 00/27] Latest numa/core release, v16

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 21 Nov 2012 20:31:12 -0800 (PST)
From:	David Rientjes <rientjes@...gle.com>
To:	Ingo Molnar <mingo@...nel.org>
cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Mel Gorman <mgorman@...e.de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-mm <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>,
	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 Wed, 21 Nov 2012, Ingo Molnar wrote:

> Btw., what I did was to simply look at David's profile on the 
> regressing system and I compared it to the profile I got on a 
> pretty similar (but unfortunately not identical and not 
> regressing) system. I saw 3 differences:
> 
>  - the numa emulation faults
>  - the higher TLB miss cost
>  - numa/core's failure to handle 4K pages properly
> 
> And addressed those, in the hope of one of them making a
> difference.
> 

I agree that it's worth a try and if it's helpful to your debugging then 
I'll always commit to trying things out.  I've pulled tip#master at 
9f7b91a96bb6 ("Merge branch 'x86/urgent'") and performance improves 0.3% 
with 16 warehouses with vsyscall=emulate, i.e. a revert of 01e9c2441eee 
("x86/vsyscall: Add Kconfig option to use native vsyscalls and switch to 
it") so I'd recommend that gets dropped based on my results and Andy's 
feedback unless anybody can demonstrate it's better (which very well may 
be the case on some systems, but then again that's why its configurable 
from the command line).

You're also completely right about the old glibc, mine is seven years old; 
I can upgrade that since I need to install libnuma as well on this box 
since you asked for the autonuma topology information that I haven't 
forgotten about but will definitely get around to doing.

> There's a fourth line of inquiry I'm pursuing as well: the node 
> assymetry that David and Paul mentioned could have a performance 
> effect as well - resulting from non-ideal placement under 
> numa/core.
> 
> That is not easy to cure - I have written a patch to take the 
> node assymetry into consideration, I'm still testing it with 
> David's topology simulated on a testbox:
> 
>    numa=fake=4:10,20,20,30,20,10,20,20,20,20,10,20,30,20,20,10
> 

This very much may be the case and that characteristic of this box is why 
I picked it to test with first.  Just curious what types of topologies 
you've benchmarked on for your results if you have that available?  An 
early version of sched/numa used to panic on this machine and Peter was 
interested in its topology (see https://lkml.org/lkml/2012/5/25/89) so 
perhaps I'm the only one testing with such a thing thus far?
--
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/