Date: Thu, 06 Jun 2002 02:12:32 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Stephen Montgomery-Smith <stephen@math.missouri.edu> Cc: freebsd-hackers@freebsd.org Subject: Re: allocating memory Message-ID: <3CFF2780.FAD81226@mindspring.com> References: <3CFEEB99.AEDC5DB9@math.missouri.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Stephen Montgomery-Smith wrote: > I have access to a rather large computer (3GB of RAM) and I would like > to write a program to access most of this memory. I find that I am > unable to malloc more than about 0.5 GB of memory, even if I do it in > small increments. Now I am trying mmap, and this lets me get to about > 2.5 GB of memory (again I ask for the memory in small increments). What > is it that causes these limitations? You never allocate physical memory, you only ever allocate virtual memory. The amount of memory is limited by your address space. For most machines, this is limited by the number of pins on the CPU to 32 bits. Since the kernel must be able to access both the process memory, and the kernel memory, at the same time, this means that the virtual address space is split between kernel memory and user memory (or the kernel would not be able to copy data between user buffers and those in the kernel). So the actual amount of virtual memory usable by a user program is: 4G - KVA space By default, in 4.x, the KVA space was 1G, which meant that use space programs were limited to 3G in size. It turns out that 1G is not enough KVA space for a 4G machine, since there is a lot of overhead associated with the VM system being able to manage 1M pages of memory. Some of that is in the overallocation of swap space (for any guve UVA space [process], you are limited to UVA = physical mappings + swap mappings). So in order to make sure that maxed-out (4G) machines even boot, the KVA space has to be increased. 3G is about the top of what you can have without this. Why doesn't malloc work to get all the memory it can? I don't know; you would have to petition PHK for an answer as to why, since he is the author of the malloc you are using. If it's not "pilot error", then it's probably something broken that he'll have to fix (no user serviceable parts). As for topping out at ~2.5G: yes: that's what's expected. If you really need more memory than that, you will need to drop ~US$10K on a 64 bit Itanium machine, and petition Peter Wemm for the correct dead chicken to wave over the thing. In general, I'd suggest that, unless it's for non-swappable kernel structures, you should just trust the system to Deal With The Memory and Do The Right Thing Automatically: only think in terms of the virtual memory, and ignore the physical. If you need a larger amount of memory in one program simultaneously, you should partition your problem so you can make do with less memory (e.g. if you are writing a linker-to-end-all-linkers, then consider not mapping all the object files simultaneously, and using an LRU and writing your own "as needed" mapping layer, instead, so you don't need it all simultaneously, and addresses can overlap). If you can't do that, and *must* have a larger amount of address space in your programs... welcome to the Itanium owners club of America. We meet once a month to race our machines in the big parking lot on Sundays; bring lots of water, a sack lunch, and orange cones, if you have them. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3CFF2780.FAD81226>