On Sat, 18 Mar 2000 15:38:56 +0000, you wrote:
>James Sutherland wrote:
>> On Thu, 16 Mar 2000, Paul Jakma wrote:
>> > On Thu, 16 Mar 2000, James Sutherland wrote:
>> > > On Wed, 15 Mar 2000, Paul Jakma wrote:
>> > > That doesn't happen. malloc() ALLOCATES the memory to the process. It is
>> > > *NOT* overcommitted. It may be backed by swapspace rather than physical
>> > > memory, but that block of memory *IS* available to the process.
>> >
>> > so malloc() isn't overcommited? malloc()'ed memory is guaranteed to be
>> > available - ie the memory is reserved and accounted for at malloc()
>> > time?
>>
>> malloc() CAN be overcommitted. If you set a VM flag via /proc, then
>> malloc() will *ALWAYS* succeed, even if there isn't any memory available
>> at all. With the flag clear, malloc() does some sanity checking before
>> granting the memory.
>>
>> You CAN obtain an overcommit free malloc() by clearing the VM flag (it is
>> clear by default), then touching every page you allocate when you allocate
>> it.
>
>No, this will just result in your process SIGBUS'ing. The current
>do_mmap (in mmap_fixup) will call make_pages_present(). There's no error
>return. It'll just die if one of the pages could not be faulted.
However it is handled, you now know that your memory allocation
succeeded and you have real memory on your hands, not just an IOU. If
there isn't any memory available, you get SIGBUSed - but then OOM
conditions usually lead to death anyway.
James.
-
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/
This archive was generated by hypermail 2b29 : Thu Mar 23 2000 - 21:00:27 EST