Marco Colombo writes:
> On 18 Mar 2000, Mirian Crzig Lennox wrote:
>> Overcommitting memory is the moral equivalent of writing bad checks and
>> praying there will be money to cover them before they are cashed. It's
>> completely irresponsible-- and when it fails, it really bites down hard.
> I must be missing something. How can you compare the two things?
> brk() is just extending your virtual address space. Your VA space
> has little to do with RAM or swap, just because is *virtual*. It just
> means that 0xe0000000 is not a *real* address, just a translated ones...
The debate is (in part) about whether brk(2) should just extend the
address space of a process, or also arrange for virtual memory for
that address range to be reserved at that point of time.
At this point, the kernel would not need to decide which particular
pages of memory or swap are to be allocated, just that the known
reserve is descreased by the requested amount.
The underlying assumption is that processes do indeed use the address
space they request, which implies that the virtual memory would have
to be made available anyway in the long run.
> As someone already pointed out, i may need it just to implement some
> sparse algorithm without having to handle a translation table and
> a cache myself.
Granted, but is this the norm or the exception? I believe the latter.
Note that if you want to use this technique, you'd better _know_ that
the system you're on overcommits, or you end up wasting gobs of
memory. It is therefore not something a reasonably portable program
can do.
On ther other hand, most programs do not use sbrk(2) to obtain memory,
they use malloc(3). The difference is that (following the C standard)
there is a guarantee that if malloc succeeds, then the memory can be
used. On a system that unconditionally overcommits, this guarantee
doesn't hold.
To put it in a different way: if a program crashes because it
dereferences a NULL returned by malloc, the program has a bug. If it
crashes because on dereferencing a non-NULL pointer returned by malloc
there is no virtual memory available, then the C runtime is at fault.
In any case, it seems people are now mostly shooting the same
arguments at each others. More constructive (but definitely more
work) would be to instrument a kernel to actually keep track of memory
in sufficient detail, and (for example) log messages when it is
overcommitting. This would give actual information about the costs
and exactly how often overcommitment occurs in normal use. If only I
had the time...
-- Olaf WeberDo not meddle in the affairs of sysadmins, for they are quick to anger and have no need for subtlety.
- 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:35 EST