From: Rusty Russell <rusty@rustcorp.com.au>
To: Peter Zijlstra <peterz@infradead.org>, mingo@kernel.org,
        mathieu.desnoyers@efficios.com, oleg@redhat.com,
        paulmck@linux.vnet.ibm.com, torvalds@linux-foundation.org
Cc: linux-kernel@vger.kernel.org, andi@firstfloor.org, rostedt@goodmis.org,
        tglx@linutronix.de, laijs@cn.fujitsu.com, linux@horizon.com,
        peterz@infradead.org
Subject: Re: [PATCH v6 0/9] latched RB-trees and __module_address()
In-Reply-To: <20150506135139.751304211@infradead.org>
References: <20150506135139.751304211@infradead.org>
User-Agent: Notmuch/0.17 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu)
Date: Thu, 07 May 2015 10:50:39 +0930
Message-ID: <87oalx89p4.fsf@rustcorp.com.au>
MIME-Version: 1.0
Content-Type: text/plain
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2032
Lines: 56

Peter Zijlstra <peterz@infradead.org> writes:
> This series is aimed at making __module_address() go fast(er).

Acked-by: Rusty Russell <rusty@rustcorp.com.au> (module parts)

Since all the interesting stuff is not module-specific, assume
this is via Ingo?  Otherwise, I'll take it...

Thanks,
Rusty.

>
> 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 measured on my ivb-ep system with 84 modules loaded; the test module 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
>
> 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:
>
>  - rebased against Rusty's tree
>  - raw_read_seqcount_latch() -- (mingo)
>
> Based on rusty/linux.git/pending-rebases; please consider for 4.2
>
> Thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/