Re: [Cvs-test-results] CVS trunk testing results (BSDI BSD/OS)

[Derek Price]

Larry Jones wrote:

>However, it's failing about 4MB into the 7MB file, which worries me
>since that's nowhere near my process limits.  And, indeed, at this point
>I can malloc() lots of memory with no problem, but pagealign_alloc()
>fails:
>
>(gdb) p pagealign_alloc(4096)
>$6 = (void *) 0x0
>(gdb) p malloc(4096)
>$7 = 143335424
>(gdb) p malloc(40960)
>$8 = 143339520
>
>So, I think there's a problem with the way pagealign_alloc() uses
>mmap().
>  
>

It is possible. My Linux mmap man page says: ENOMEM is set when "No
memory is available, or the process’s maximum number of mappings would
have been exceeded." Could you count the number of times mmap is called
(probably minus calls to munmap) before failing and see if it looks to
be a consistent number?

Before you try to do this, it might be instructive to verify the values
for HAVE_MMAP & HAVE_MAP_ANONYMOUS from your BSDI config.h to make sure
we really understand the code path. :)

>I note that on my system, malloc() claims to page align large requests
>-- maybe we're trying too hard.
>  
>

Maybe in what sense? I gather that some systems don't automatically
align large malloc requests, or this GNULIB module probably would not
exist. Are you suggesting that we shouldn't care and CVS should simply
run slower on any systems that don't align large requests to the page
boundry automatically? I'm not personally sure how drastic the speed
decrease would be on uncooperative systems, but I would guess in the
worst-case double the number of page faults, and twice the disk access
could be a big deal with the amount of data CVS transfers.

Alternatively to dropping use of pagealign_alloc completely, though more
labor-intensive, a configure test could determine if the result of
malloc (getpagesize()) looked to be aligned or not and choose to use
avoid pagealign_alloc (or internally to pagealign_alloc, avoid mmap)
when malloc appears to return aligned pages. Of course, I seem to recall
the reason that GNULIB preferred mmap to pagealign_alloc in the first
place was that posix_memalign on most systems just allocated (size +
pagesize - 1) or more bytes and returned the first page boundry within
the allocated memory, which can waste up to a page of memory (and would
in CVS, since we always request a page from the buffer functions,
posix_memalign would always allocate 2 pages) - if posix_memalign does
this, then I would expect similar from aligning mallocs, but I don't
really know. If you aren't arguing that we stop using the
pagealign_alloc module completely, it might be useful to bring this up
on bug-gnulib. (I'm not sure why mmap does not waste memory this way,
but apparently it does not:
<http://lists.gnu.org/archive/html/bug-gnulib/2005-03/msg00023.html>.)

Regards,

Derek

-- 
Derek R. Price
CVS Solutions Architect
Ximbiot <http://ximbiot.com>
v: +1 717.579.6168
f: +1 717.234.3125
<mailto:derek@ximbiot.com>