[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <55997889.5020101@internode.on.net>
Date: Mon, 06 Jul 2015 04:03:45 +0930
From: Arthur Marsh <arthur.marsh@...ernode.on.net>
To: linux-kernel@...r.kernel.org
CC: Peter Zijlstra <peterz@...radead.org>,
Rusty Russell <rusty@...tcorp.com.au>,
Steven Rostedt <rostedt@...dmis.org>,
Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
Oleg Nesterov <oleg@...hat.com>,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Subject: lock-up with module: Optimize __module_address() using a latched
RB-tree
On this machine, a single core Athlon 64 with a 32 bit current Linus'
git head kernel, I get a lock-up early in the boot process. (A dmesg
output of a successful boot-up of kernel 4.1.0 up to and slightly passed
the point where the git head kernel locks up is attached).
A photo of the lock-up appears at:
http://www.users.on.net/~arthur.marsh/20150706462.jpg
git-bisect reveals the bad commit as:
git bisect good
93c2e105f6bcee231c951ba0e56e84505c4b0483 is the first bad commit
commit 93c2e105f6bcee231c951ba0e56e84505c4b0483
Author: Peter Zijlstra <peterz@...radead.org>
Date: Wed May 27 11:09:37 2015 +0930
module: Optimize __module_address() using a latched RB-tree
Currently __module_address() is using a linear search through all
modules in order to find the module corresponding to the provided
address. With a lot of modules this can take a lot of time.
One of the users of this is kernel_text_address() which is employed
in many stack unwinders; which in turn are used by perf-callchain and
ftrace (possibly from NMI context).
So by optimizing __module_address() we optimize many stack unwinders
which are used by both perf and tracing in performance sensitive code.
Cc: Rusty Russell <rusty@...tcorp.com.au>
Cc: Steven Rostedt <rostedt@...dmis.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Cc: Oleg Nesterov <oleg@...hat.com>
Cc: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@...radead.org>
Signed-off-by: Rusty Russell <rusty@...tcorp.com.au>
:040000 040000 1d6863a47d8521a4edbe44f9e7c3422ad1421d61
a209090da5e67f56f0997671f5a8b510338511ba M include
:040000 040000 da680638e9cebc8da54d43cc0e67b77b953430fa
31063f7ed575d22f0d27b24c76b9a0fb68c7cd40 M kernel
I am happy to supply further details and run further tests.
Arthur.
View attachment "dmesg20150706.txt" of type "text/plain" (44265 bytes)
Powered by blists - more mailing lists