Messages in this thread | | | Date | Tue, 8 Feb 2000 15:14:19 -0500 (EST) | From | Lee Chin <> | Subject | Re: maximum memory limit |
| |
Just to make sure I have this correct, an application can call brk to allocate memory from its heap space for upto 1GB, after which it has to switch to using mmap for the rest. Is this 1GB fixed or will it ever change? (if it does, it might break my application).
>around 900M if the malloc uses sbrk, but more if it uses mmap. >modern libc's will use mmap for large allocations, since unlike >sbrk, mmap can actually free memory back to the OS.
Which version of libc has malloc that uses mmap after 1GB?
>lots of trivial-sized allocations are a really bad idea in any case. >doing it in 1M chunks will give you more like 3G.
But what if I have an application that doesent know how much memory it will need? My application is reading in a file, parsing it and constructing a huge in-memory database. Should I write my own library that will first mmap a large (say 2 GB) memory and then dish out smaller chunks to the application from there on an as need babsis? This is what malloc should really do. What is the general approach taken for these kind of applications?
> the issue is > actually that the kernel normally permits 3G of VM to each task, > but starts mmaped allocations at the 1G mark. that limits the sbrk
It seems complicated for an application that wants to use a large amount of memory to know that it first has to use brk then switch to mmap after a 1GB... or am I understanding this incorrectly? It also might break portability, right?
> heap, of course. but it's easy and not harmfull to shift the > starting point for mmap if you must use tiny mallocs. a better How do I do this? Is this a kernel change?
> solution would probably be to have mmaped areas start at 3G and > grow down, but that's not in the kernel yet.
> regards, mark hahn.
Thank you all very much :)
______________________________________________ FREE Personalized Email at Mail.com Sign up at http://www.mail.com?sr=mc.mk.mcm.tag001
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |