Re: [Valgrind-users] Swap Space Problem

[John R. <jr...@Bi...>]

Olly Betts wrote:
> On Mon, Jun 16, 2003 at 06:57:07PM -0700, John Reiser wrote:
>>Insure++ for Linux/x86 has a "no preparation required" checking mode
>>which for large processes has a memory overhead factor close to 1/4
>>[total usage while monitoring is a factor of about (1 + 1/4) times the
>>non-monitored usage].
> 
> 
> Is this mode similar to valgrind's --skin=addrcheck?  According to the
> documentation, that has an overhead of about 1/8 (compared to 9/8 for
> memcheck).
> 
> Or does 1/4 mean that it's also tracking validity at the byte level
> (rather than at the bit level as memcheck does)?

It tracks addressability, and contents validity at the byte level.  So some
uses of bitfields trigger "false positive" complaints the first time.
[This can help identify performance bottlenecks.  Compilers may generate
slow code for consecutive accesses to adjacent bitfields.]
Also, the factor of 1/4 does not count the usual "red zone" padding
around allocated blocks.  The red zone can be adjusted, trading off
depth of traceback that is recorded at malloc and free.

If the original complaint
-----
VG_(get_memory_from_mmap): request for 8192 bytes failed.
VG_(get_memory_from_mmap): 2119042790 bytes already allocated.
-----
arose when many large blocks (say, several megabytes each) had been
free()d recently, then the delayed free list may be hoarding the space.
Reduce the length of the delayed free list, and try again.  This gives
you less protection for "referenced after being free()d", of course.