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:[EMAIL PROTECTED]> _______________________________________________ Bug-cvs mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/bug-cvs
