Re: [bug-gnulib] valloc()?

[Derek Price]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Bruno Haible wrote:

|> (Most of this is hardly necessary for CVS since it is already
|> caching unused buffer datas rather than freeing them, and reusing
|> them as they are needed.
|
|
| This is actually a bad idea, because 1) It steals memory from the
| system. If a program doesn't use memory but still holds it, it
| forces other programs to do more page faults. 2) When memory is
| tight, it forces the system to write garbage data to swap space. 3)
| It slows down 'cvs' itself. Because when the page gets swapped out
| to disk, and the the program notices that it needs it, the OS must
| re-fetch the page from the swap. This usually takes ca. 10 ms.
|
| Whereas when a program munmap()s the pages that it doesn't need any
| more, 1) Other programs can use the free mempry. 3) When the
| program needs more memory, the kernel can often provide a blank
| page immediately, without having to wait for a swapped out page to
| come in.


This covers the mmap and posix_memalign issues, but on systems where
is is necessary to fall back on valloc, there is still the issue of
not freeing the memory, which with a transaction against a large CVS
repository could be gigabytes worth of memory, especially considering
that much CVS data will travel through two or more buffers before it
reaches its destination.

Therefore, I am going to try to implement what you suggest, but in the
valloc() fallback case, I am going to actually call valloc.  I am
going to use the replacement code above and save a table of returned
(aligned) pointers mapped to the original allocated pointer and
consult the map to free the original pointer in pagealign_free();

Thanks and Regards,

Derek
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD4DBQFCJhfZLD1OTBfyMaQRAgdiAJiSub1QdJuH6PuZb7LTQiX6uiWRAJ9qtddf
v6hdnif6sNEUQDMjPa2Alw==
=ysGL
-----END PGP SIGNATURE-----