Cc: Bart Van Assche <bart.vanassche@...>, Pekka Enberg <penberg@...>, Linux Kernel Mailing List <linux-kernel@...>, Ingo Molnar <mingo@...>, Peter Zijlstra <a.p.zijlstra@...>, Paul E. McKenney <paulmck@...>, Christoph Lameter <clameter@...>, Daniel Walker <dwalker@...>, Andi Kleen <andi@...>, Randy Dunlap <randy.dunlap@...>, Josh Aune <luken@...>, Pekka Paalanen <pq@...>
The speed of Valgrind+UML is the same as the speed of valgrind
on any application. On a 2GHz box it took about 2.5 minutes
to reach "login:" from a cold boot of UML (includes udev, etc.)
So if normal boot takes 15 seconds, then that's a factor of 10
slowdown: slow for interactivity, yet bearable for checking.
The memory-intensive portions (linear search, pointer chasing,
etc.) can be slower still, but loops that concentrate on
register arithmetic or conditional branching go faster.
There is almost no system wait time: normal device delays (disk,
network) get totally overlapped by CPU usage for grinding :-)
I'd like to have both kmemcheck and valgrind+UML, and use them
differently. Run kmemcheck all the time on a box or two as
"background trolling" for infrequent cases. Use valgrind+UML
for interactivity and programmable flexibility when hunting
specific bugs, or when hardware cannot be dedicated.
--
John Reiser, jreiser@BitWagon.com
--
