Re: [ANNOUNCE] kmemcheck v7

21 msg	performance 'regression' in cfq compared to ant...
1 msg	[PATCH] char/synclink_gt: fix uninitialized ret...
1 msg	[PATCH] kill generic_file_direct_IO
1 msg	[PATCH] gigaset: gigaset_isowbuf_getbytes() may...
1 msg	[PATCH] gigaset: use dev_ macros for messages
3 msg	Re: 2.6.26-rc1: possible circular locking depen...
1 msg	[GIT pull] x86 updates for 2.6.26
1 msg	page vs. fs-cache
1 msg	[OP] v2.6.22.24-op1
1 msg	[PATCH] i2c: adds support for i2c bus on Freesc...
2 msg	[PATCH] [POWERPC] Add i2c pins to dts and board...
2 msg	[PATCH] kmemcheck: use set_memory_4k() instead ...
1 msg	Regression caused by bf726e 'semaphore: fix'
1 msg	[patch] linux/atm_tcp.h linux/atm.h: cleanup fo...
8 msg	asm-{alpha,h8300,um,v850,xtensa}/param.h: unbre...
2 msg	[PATCH] /fs/partition/check.c: fix return value...
3 msg	ppc compile failure (__flush_icache_range etc u...
1 msg	2.6.25-$sha1: RIP __call_for_each_cic+0x20/0x50

Re: [ANNOUNCE] kmemcheck v7
\ Bart Van Assche (10 May 2008)
. \ Pekka Enberg (10 May 2008)
. . \ Bart Van Assche (10 May 2008)
. . . \ Vegard Nossum (10 May 2008)
. . . . \ Andi Kleen (10 May 2008)
. . . . . \ Bart Van Assche (10 May 2008)
. . . . . \ Jeremy Fitzhardinge (10 May 2008)
. . . . . . \ Andi Kleen (10 May 2008)
. . . . . . . \ Jeremy Fitzhardinge (10 May 2008)
. . . . . . . . \ Andi Kleen (10 May 2008)
. . . . . . . . . \ Jeremy Fitzhardinge (10 May 2008)
. . . . . . . . \ John Reiser (10 May 2008)
. . . . . . . . . \ Jeremy Fitzhardinge (10 May 2008)
. . . . \ Bart Van Assche (10 May 2008)
. . . . \ Jeremy Fitzhardinge (10 May 2008)
. . . . . \ Jeff Dike (10 May 2008)
. . . . . . \ John Reiser (11 May 2008)
. . . . \ John Reiser (11 May 2008)

1 msg	[PATCH] eCryptFS: fix imbalanced mutex locking

Subject:	Re: [ANNOUNCE] kmemcheck v7
Group:	Linux-kernel
From:	John Reiser
Date:	11 May 2008

Vegard Nossum wrote:
> How is the speed of Valgrind+UML, does anybody know?

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/