Can some one clarify the maximum memory can be allocated malloc() function call...??
As per my knowledge memory is divided in to number of chunks with with different size in each chunk, and malloc allocates ccontinuous cunk of memory block....

Yes the maximum memory can be allocated by using malloc() function.

Once I was trying to figure out how much memory I can malloc to maximum extent on my machine. I read that most computers/OSs support virtual memory, backed by disk space.
Also when a program exceeds consumption of memory to a certain level, the computer stops working because other applications do not get enough memory that they require.

malloc() asks the OS, which in turn may well use some disk space.

my question is the maximum successful memory allocated by a malloc() in a single.

Assume there is no other processes running in the user space of the computer....

Sorry, I didn't get you. Please give some more description of your problem.

Here you say ....in a single, single what?

Please give more description for your problem.

malloc() is a library function. In Linux, there are two syscalls that can be used to allocate new memory for a process: sbrk() and mmap() .

The maximum amount of memory a process can allocate, is limited by kernel-enforced per-process limits. See man setrlimit and the RLIMIT_AS and RLIMIT_DATA limits for details. When Pluggable Authentication Modules (PAM) is used, those are often set using pam_limits module; see limits.conf somewhere under /etc/ (the location varies from Linux distribution to distribution).

For a 32-bit process, the absolute maximum amount of memory a process can allocate depends on kernel configuration, and varies from 1 gigabyte to 3 gigabytes. This split is configurable when the kernel is compiled.

Because processes do not always actually use (access) all the memory they ask from the kernel, a policy called overcommit is used by most Linux systems. This means that the kernel will allow allocations to exceed the total amount of RAM and SWAP available. This is a configurable setting, and in certain cases it is useful to turn it off, in which case the amount of RAM and swap available is the absolute limit for any new allocation.

For a 64-bit process, the maximum amount of memory a process can allocate depends on various factors. Normal allocations (for example, using malloc()) are limited by the available RAM and swap, adjusted depending on the overcommit policy. File-backed allocations (memory-mapped files), however, can greatly exceed the amount of RAM and swap available. As an example, here is a simple example program in C I wrote in an earlier thread, that creates a terabyte (1099511627776 bytes) memory map using a sparse file. For the application, it does look like it just had allocated a terabyte of RAM, as the kernel takes care of which pages (parts of the map) are in RAM, and which are stored in the file.

The maximum possible size of a memory map is limited by the available RAM, since the kernel needs to keep track of each page in the map, and these structures must stay in RAM. I believe the structures alone need about two gigabytes of RAM for each terabyte mapped (1:512 ratio). However, much sooner than than the RAM limit is approached, the usefulness of the map degrades. The kernel needs some RAM to keep most used pages of the map in RAM, or it will end up writing and reading each page to and from the disk for every access; this is at least a million times slower than normal operation! (If your accesses are mostly to the same page, the slowdown is much smaller.)

Therefore, on 64-bit Linux systems, the "absolute allocation maximum" is irrelevant, as it would be counterproductive to try to allocate that much. As a programmer, the fact that you can always allocate all available RAM, and/or map a file several dozen times the size of available RAM, should suffice.

I don't believe that is correct.
I think pages of the page tables can be paged out to swap. They can also be missing entirely for sparse enough sections of the mapping.

The portion of the page table data structure needed to support the hardware TLB miss resolution is in that 1:512 ratio (one 4KB page of mapping data for every 512 4KB pages mapped). But I think Linux requires extra page table data beyond what the hardware needs, so the ratio is worse than 1:512.

I just want to let you know just how valuable this thread has been to us. I had never heard of the overcommit feature for memory allocation in Linux.

We run Ubuntu Linux in a pXe-booted RAM-based environment. A server provides the kernel, initrd and an NFS-mounted root filesystem. The pXe boot copies the NFS filesystem to a RAM-disk and unmounts the NFS filesystem. Thus, everything is running from RAM. There is no swap space.

We've run into problems where processes that use huge amounts of buffer memory get killed. That was all it said: "Killed." The only reason we knew it was because of the memory allocation is that the application did a malloc, which never returned.

By using sysctl to change the vm.overcommit_memory variable to 2 (instead of the default of 0), we now get a NULL pointer from the malloc, which is far better than just being killed. The application can usually then let the tester allocate a smaller buffer to perform his/her tests.

Thanks.