Can one process really use 3 Gig RAM on Linux?
Daniel Wilkerson
Kernel isn't a problem, but that the malloc libraries just won't
allocate beyond 1 Gig. Is buying a machine with 3 Gig RAM just a
waste of money then? I have code to run which would use this much RAM
if it were there and accessible.
heath
3 Gig is way over kill.
heath
Eric P. McCoy
> What the hell are you running? Unless your running a high capactiy server,
> 3 Gig is way over kill.
Please put your reply below the quoted text, as I have done.
For many applications, 3GB isn't enough; for example, machines which
do a lot of complex scientific calculations. I suspect that most of
the large-memory systems (4GB+) are actually _not_ "high capactiy
[sic] server[s]."
--
Eric McCoy (reverse "ten.xoc@mpe", mail to "ctr2sprt" is filtered)
"Last I checked, it wasn't the power cord for the Clue Generator that
was sticking up your ass." - John Novak, rasfwrj
Daniel Versick
The have to distinguish between the amount of physical RAM and the virtual
memory a process can allocate. This things have nothing to to with each
other. Even if your machine has 64 GB of RAM this doesn't mean that a
process can allocate this amount of memory. Vice versa a process can easily
allocate 1 GB of RAM even if your machine has only 128 MB RAM.
So all in all it is not senseless to have much RAM because this memory can
be used by all processes instead of swap space. (of course in some cases a
machine can even be slower with much RAM, but this is related to the
cachable area of the machine and should not be a problem an newer boxes)
Daniel
Roger Leigh
One problem is [s]brk hitting TASK_UNMAPPED_BASE, as the heap can't
grow up any more. mmap may also eventually fail too. With glibc
malloc this should not be too problematic as it uses both allocation
mechanisms as appropriate.
If you are using your own allocation mechanisms, I would suggest using
mmap only, and getting rid of brk/sbrk. I have never hit the limit
yet though.
--
Roger Leigh
** Registration Number: 151826, http://counter.li.org **
Need Epson Stylus Utilities? http://gimp-print.sourceforge.net/
GPG Public Key: 0x25BFB848 available on public keyservers
Kasper Dupont
>
> daniel_w...@yahoo.com (Daniel Wilkerson) writes:
>
> > Can one process really use 3 Gig RAM on Linux? I've heard that the
> > Kernel isn't a problem, but that the malloc libraries just won't
> > allocate beyond 1 Gig. Is buying a machine with 3 Gig RAM just a
> > waste of money then?
No, it is not a complete waste. It can still be used by other
processes, and it can also be used for caching of disk contents.
>
> One problem is [s]brk hitting TASK_UNMAPPED_BASE, as the heap can't
> grow up any more. mmap may also eventually fail too. With glibc
> malloc this should not be too problematic as it uses both allocation
> mechanisms as appropriate.
I have actually written a patch that changes TASK_UNMAPPED_BASE
from a constant to a per process variable. I have used this patch
without problems for some time, but I don't actually need that
feature. I would like some feedback stating wether it works in
real life too. The patch and a userspace code example can be
downloaded here:
http://www.daimi.au.dk/~kasperd/linux_kernel/task_unmapped_base/
A short description of the problem can be found here:
http://www.daimi.au.dk/~kasperd/comp.os.linux.development.faq.html
--
Kasper Dupont -- der bruger for meget tid på usenet.
For sending spam use mailto:razor-...@daimi.au.dk
Steve Martin
> > > Can one process really use 3 Gig RAM on Linux? I've heard that the
> > > Kernel isn't a problem, but that the malloc libraries just won't
> > > allocate beyond 1 Gig. Is buying a machine with 3 Gig RAM just a
> > > waste of money then?
>
> No, it is not a complete waste. It can still be used by other
> processes, and it can also be used for caching of disk contents.
Truly. There's no such thing as a one-process Linux box, as even
the simplest system will be running (a) the kernel and (b) INIT.