Re: setrlimit + malloc + RLIMIT_AS

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



shivaligupta wrote:
> Jim Bauer wrote:
>> Because no additional memory needed to be allocated from the kernel.
>>
> Why additional memory wont  be allocated from the kernel?
> Is it because here in this case i havent used the memory assigned to a1?
> But what i tried later is that i stored 20 numbers starting from
> location pointed by a1.

No, that has nothing to do with it.

>> It'll satisify that request for unused memory from previous allocations.
>>
> What will be the usused memory in this case?

Remember that malloc() is a library routine not a system call.
When it needs some memory to satisfy a request, it will likely
ask the kernel for more memory then was really asked for.
Much more efficient this way.  The details will vary from one
malloc implementation to another.

So lets say you do malloc(50).  The malloc implementation might allocate
a whole page or even a lot more.  Lets just say it is a page.
Then it records that 50 bytes of that page are allocated to the
caller and it still and 4096-50 still available. (I am ignoring bookkeeping
overhead.)  A bit later there is another call of malloc(30).  The
malloc code sees that the request of 30 bytes can be satisfied
in the 4096-50 bytes it still has available in its pool.  So it just
returns a portion of that.  It now has 4096-50-30 (4016) bytes available.
If later it gets a request for 4050 bytes, it sees that it can't satisify
that request in its available pool so it asked the kernel for more memory.

Only when the request for more memory needs to be made to the kernel,
will the kernel be able to enforce the resource limit.

> Yes I have read the page from the location:
> http://www.opengroup.org/onlinepubs/009695399/functions/getrlimit.html
> 
> and it says
> "RLIMIT_AS
> 
>    This is the maximum size of a process' total available memory, in
>    bytes. If this limit is exceeded, the /malloc/()
>    <http://www.opengroup.org/onlinepubs/009695399/functions/malloc.html>
>    and /mmap/()
>    <http://www.opengroup.org/onlinepubs/009695399/functions/mmap.html>
>    functions shall fail with /errno/ set to [ENOMEM]. In addition, the
>    automatic stack growth fails with the effects outlined above."
> 
> malloc is clearly mentioned.

Looks like bad wording to me.  Maybe just over simplified.
malloc() is is no position to enforce resource limits.  If they
are going to mention malloc() then they shold have included realloc(),
& calloc().  They also didn't mention brk() or sbrk().
If you s/malloc/brk/ in that page, it makes more sense to me.


>> Disable the first malloc() and you'll likely see the malloc()
>> after the setrlimit() fail.
>>
> yes i agree with that but still ii couldnt get that in the later case
> there is no unused memory available . so why memory allocation for b1
> doesn't result in failure?

See above

--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive:       http://mail.nl.linux.org/kernelnewbies/
FAQ:           http://kernelnewbies.org/faq/


[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux