lkml.org 
[lkml]   [1997]   [Feb]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Memory overcommitting
>Or, perhaps the other way around.  The majority of developers are going to
>want non-committed allocations, for the simple reason that it helps one's
>application co-exist with others. If the system enters into a situation
>where VM has become so sparse that the allocations I had previously been
>granted can no longer be met, it's a good bet that the whole enchilada is
>headed for dangerous waters. 99% of the time I would rather segfault, try
>to clean up gracefully and get out of the way of everyone else.
>Certainly, in a few instances it might be desireable to have truely
>committed allocations, but changing the allocation operation completely
>could cause a problem for existing applications (especially on lower end
>systems).

If you want truly committed memory, walk over it to forcibly allocate the
memory (hit one byte every 4k will do it) then mlock it. Ugly...




-Chris

\
 
 \ /
  Last update: 2005-03-22 13:39    [W:0.037 / U:0.128 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site