LWN: Comments on "kmemcheck"

kmemcheck

vomlehn — 2007-11-30T02:18:05+00:00

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 — 2007-11-29T19:06:18+00:00

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

kmemcheck

felixfix — 2007-11-29T18:52:21+00:00

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

kmemcheck

lysse — 2007-11-29T18:41:38+00:00

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 — 2007-11-29T18:16:17+00:00

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

kmemcheck

jreiser — 2007-11-29T15:20:52+00:00

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 — 2007-11-29T14:44:04+00:00

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 — 2007-11-29T13:19:58+00:00

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))