Per process virtual memory soft and hard limit runtime info

Submitted by floatingleaf on Wed, 09/10/2008 - 12:16.

Hey guys,

I am new to this forum so may be this is going to a wrong thread ... however it is the best I could manage ... I need to check the runtime limits of per process virtual memory ... getrlimit() is giving me RLIM_INFINITY!! Also, I am working with a 32 bit Redhat system. Even though the allowable limit should be 3 GB, the maximum dynamic memory I can allocate is ~ 2 GB (I just tried brute force iterations!). Is it because of the long datatype problem? Thanks in advance.

Per process virtual memory
Submitted by uragan on Thu, 09/11/2008 - 09:51.

Yes, this is due to long type (more particular, due to its size).

man getrlimit says:

RLIMIT_AS - The maximum size of the process's virtual memory (address space) in bytes. <...> Since the value is a long, on machines with a 32-bit long either this limit is at most 2 GiB, or this resource is unlimited.

So it's ok to get 'RLIM_INFINITY' result in your case.

per process virtual memory limit
Submitted by floatingleaf on Thu, 09/11/2008 - 14:52.

that's right buddy ... but i need to know the per process virtual memory limit at runtime .... RLIM_INFINITY won't do if my process runs out of memory!! thnx anyway

per process virtual memory limit
Submitted by uragan on Fri, 09/12/2008 - 08:02.

The right solution is to use getrlimit64 instead

It is present on 32bit systems as well as on 64bit ones, but uses 'rlim64_t' for values, which is 64bit on all systems.

per process virtual memory limit
Submitted by uragan on Thu, 09/11/2008 - 18:43.

Well, RLIM_INFINITY means that you can rely on at least LONG_MAX bytes.

If you want to check if there are some more memory available, you can try to investigate this in runtime - for example, allocate it by small portions until the allocation fails (this is just one of posible alternatives; surely, you can use smarter approaches when investigating real limit in run time).

per process virtual memory limit
Submitted by floatingleaf on Fri, 09/12/2008 - 08:43.

U r right buddy ... it is giving me LONG_MAX bytes by brute force iterations also. But getrlimit64() is not present in my version of Linux. Isn't there any smart way of doing that instead of a brute force approach? For example, how does mmap() checks that no more memory is available? Is that interface hidden from user programs? Thanks anyway.

per process virtual memory limit
Submitted by uragan on Mon, 09/15/2008 - 12:52.

getrlimit64 should be available on your system.

Just try to compile your app with '_LARGEFILE64_SOURCE' macro defined (i.e. add '-D_LARGEFILE64_SOURCE' to your cimpiler flags).

For more details about this macro see, for example, http://www.delorie.com/gnu/docs/glibc/libc_13.html

per process virtual memory limit
Submitted by floatingleaf on Wed, 09/17/2008 - 04:58.

Ya it compiled with _DLARGEFILE64_SOURCE .... thanks a lot buddy ... however, it seems I have to assume the LONG_MAX limit as this is what I m getting practically ... by the way, doesn't Windows follow any standards? It is annoying!

per process virtual memory limit
Submitted by uragan on Wed, 09/17/2008 - 13:45.

You can try something like gnuwin32 (http://gnuwin32.sourceforge.net/).

Its LibGW32C (http://gnuwin32.sourceforge.net/packages/libgw32c.htm) provides some functions with the same names and synopsis as in glibc.

per process virtual memory limit
Submitted by floatingleaf on Wed, 09/17/2008 - 13:13.

Hi ... i tried to port the program on 64 bit Linux (Redhat) but it is giving me weird result ... LONG_MAX value exceeds the actual virtual memory available by a long margin ... why is that? on 32 bit Linux it is working fine.

Per process virtual memory soft and hard limit runtime info

Active forum topics