LWN: Comments on "kmemcheck"

kmemcheck

vomlehn — Fri, 30 Nov 2007 02:18:05 +0000

I would say that this idea pretty much rocks. Yes, it will slow the kernel way down and that
will make it unusable for production use, but the ability to do these checks on debugging
kernels is an excellent idea and the implementation makes a lot of sense for a first cut.

kmemcheck

nix — Thu, 29 Nov 2007 19:06:18 +0000

Also the extra memory accesses will tend to blow the cache more if you use 
more memory to track the uninit state.

kmemcheck

felixfix — Thu, 29 Nov 2007 18:52:21 +0000

Well, hmmmm, I guess I was thinking just enough to stick my foot in my mouth :-)

kmemcheck

lysse — Thu, 29 Nov 2007 18:41:38 +0000

When there's already a page fault happening on every memory access, I have some doubts of the
significance of such additional overhead.

kmemcheck

felixfix — Thu, 29 Nov 2007 18:16:17 +0000

The code to map bits would be slower; maybe he did not like the tradeoff.

kmemcheck

jreiser — Thu, 29 Nov 2007 15:20:52 +0000

On a 32-bit machine it is tempting to use 8 bits (an entire byte) to track access to 32 bits
(one word) of memory.  This gives speed while still saving some space.

kmemcheck

nix — Thu, 29 Nov 2007 14:44:04 +0000

A bitmap definitely can be used instead. (This is how valgrind's memcheck 
tool implements uninitialized checks, although using JIT simulation rather 
than page faulting to detect accesses.)

kmemcheck

dw — Thu, 29 Nov 2007 13:19:58 +0000

Doubling the size of every allocation seems pretty wasteful, couldn't a bitmap be used
instead, with byte or even word-level granularity?

new_size = (size + (size/8))