Actually i cannot understand how this "optimistic
memory allocation strategy" works.
It is normal all requested memory to be allocated
before malloc returns any result. At this moment it
seem to be something like alloc on demand, and this
requires special flag, otherwise there gonna be
CoreDump.
I don't have glibc sources but i assume that malloc is
translated to vmalloc.
Malloc should be able to alloc pages in ram and swap.
Currently the memory management seems to be separated
in two independent parts, RAM management and swap
transfer. Instead of working as one, the swap is used
to keep amount of pages free. In this situation it is
impossible to make correct routine that allocates more
memory than are available as free pages. And even
worse, kswapd is called 0.5 times per second, or on
page fault. At least it should be linked with routines
that allocate memory. But in this implementation the
effect could be negative. More, kswapd is used to
reduce buffer and cache.
The 2.4.x memory management should be fixed now.
The quick fix could be to use
mm/mmap::vm_enough_memory, to check amount of free
pages in vmalloc. The strange thing is that this
function is used in shmem.c that hold tmpfs. So
please, synchronize this with
mm/oom_kill.c::out_of_memory. And please don't balance
things out, be more paranoid.
I first thought to use out_of_memory (with some
tweaking) to check vmalloc, because this will force
use of oom_kill only after huge kmalloc.
This optimistic allocation should be removed , because
there are some horrible workarounds for this.
About the beancounter: I don't know this algorithm,
but i don't need group based resources accounting. For
me the things are simple - give memory if there is
any. If there is not don't give loans, Linux is not a
bank!!!! :)
__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Aug 23 2001 - 21:00:57 EST