On Nov 23, 2005, at 2:56 PM, Arne Wörner wrote:
--- Michael Conlen <[EMAIL PROTECTED]> wrote:
On Nov 23, 2005, at 1:20 PM, Arne Wörner wrote:
Maybe the stack size matters in ur case somehow? I can see,
that
it is limited to 1GB, isn't it?
I found something funny, too:
limit
cputime unlimited
filesize unlimited
datasize 524288 kbytes
stacksize 65536 kbytes
coredumpsize unlimited
memoryuse unlimited
vmemoryuse unlimited
descriptors 6861
memorylocked unlimited
maxproc 3430
sbsize unlimited
c++ -o mmap mmap.c
./mmap 757254143
sz2d22c7ff00000 r673435648 errno0
cat mmap.c
#include <sys/mman.h>
#include <stdio.h>
#include <errno.h>
#include <stdlib.h>
int main(const int argc, char ** argv) {
void * r =
mmap(0,atoi(argv[argc-1])*1024LL*1024,0,MAP_ANON|MAP_PRIVATE,-1,0);
printf("sz%llx r%d
errno%d\n",atoi(argv[argc-1])*1024LL*1024,r,errno);
return 0;
}
<EOF>
-Arne
At this point I have updated the kernel to include
2 GB for stack and data size and edited the
loader.conf to include those options as well
with the same result. I really believe the system is
being limited elsewhere.
But why can I get so much memory (722TB) with mmap (even with the
default MAXDSIZ in my kernel)?
Maybe we use mmap(2) the wrong way (I just used it with files: I
found it fancier to write to a file via mmap(2)'ed memory)?
Well, I'm not trying to use mmap() this way per say, java 1.4.2 and
1.5.0 built from ports is.
I have verified that I can malloc() much more memory that I can mmap
(). I'm looking at the code for mmap() and I can't find a resource
limit that would normally return ENOMEM that is set too low.
--
Michael Conlen_______________________________________________
freebsd-performance@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
