linux-kernel - Re: [PATCH v5 00/10] latched RB-trees and __module

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]

Message-ID: <20150413170237.GA26512@gmail.com>
Date:	Mon, 13 Apr 2015 19:02:38 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	rusty@...tcorp.com.au, mathieu.desnoyers@...icios.com,
	oleg@...hat.com, paulmck@...ux.vnet.ibm.com,
	torvalds@...ux-foundation.org, linux-kernel@...r.kernel.org,
	andi@...stfloor.org, rostedt@...dmis.org, tglx@...utronix.de,
	laijs@...fujitsu.com, linux@...izon.com
Subject: Re: [PATCH v5 00/10] latched RB-trees and __module_address()


* Peter Zijlstra <peterz@...radead.org> wrote:

> This series is aimed at making __module_address() go fast(er).
> 
> The reason for doing so is that most stack unwinders use kernel_text_address()
> to validate each frame. Perf and ftrace (can) end up doing a lot of stack
> traces from performance sensitive code.
> 
> On the way there it:
>  - annotates and sanitizes module locking
>  - introduces the latched RB-tree
>  - employs it to make __module_address() go fast.
> 
> I've build and boot tested this on x86_64 with modules and lockdep
> enabled.  Performance numbers (below) are done with lockdep disabled.
> 
> As previously mentioned; the reason for writing the latched RB-tree as generic
> code is mostly for clarity/documentation purposes; as there are a number of
> separate and non trivial bits to the complete solution.
> 
> As measued on my ivb-ep system with 84 modules loaded; prior to 
> patching the test module (below) reports (cache hot, performance 
> cpufreq):
> 
>           avg +- stdev
> Before:   611 +- 10 [ns] per __module_address() call
> After:     17 +-  5 [ns] per __module_address() call
> 
> PMI measurements for a cpu running loops in a module (also [ns]):
> 
> Before: Mean: 2719 +- 1, Stdev: 214, Samples: 40036
> After:  Mean:  947 +- 0, Stdev: 132, Samples: 40037

Those are some pretty impressive speedups!

I suspect the 900 nsecs residual PMI overhead is due to other, overly 
bloated PMI (perf) processing costs?

> Note; I have also tested things like: perf record -a -g modprobe 
> mod_test, to make 'sure' to hit some of the more interesting paths.
> 
> Changes since last time:
> 
>  - reworked generic latch_tree API (Lai Jiangshan)
>  - reworked module bounds (me)
>  - reworked all the testing code (not included)
> 
> Rusty, please consider merging this (for 4.2, I know its the merge 
> window, no rush)

So modulo the mostly trivial feedback I gave, it looks all good to me 
as well, feel free to also add my:

  Reviewed-by: Ingo Molnar <mingo@...nel.org>

Thanks,

	Ingo
--
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/