>>> Overcommit tracking must be system_wide, but it doesn't need
>>> to apply to all processes. If data for all processes is kept,
>>
>> Choosing overcommitment on a per-process basis sounds like a
>> good idea (though probably painful to setup since you'd have to
>> specify process by process, but you could probably have a
>> default of overcommit==(! user==root)).
>>
>> Turning off overcommitment doesn't save you from figuring out
>> what to do when you run out of memory (return NULL from malloc
>> is very nice, but if this malloc was executed by /sbin/init,
>> it might not be such a good idea).
Have /sbin/init disable overcommit on itself after swap is on.
> glibc handle a malloc directly with mmap() so overcommit
> pratically does nothing right now in a glibc system I think.
>
> (overcommit is a check that _sbrk()_ does before use mmap to
> map the memory)
We don't do any serious tracking now, so it doesn't matter.
Maybe Linux 2.3 will plug all the holes: sbrk(), mmap(),
mprotect(), the debugger interface, etc.
-
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/