Re: Overcomittable memory

From: James Sutherland (jas88@cam.ac.uk)
Date: Mon Mar 20 2000 - 14:53:32 EST


On 20 Mar 2000 15:53:20 +0100, you wrote:

>Den 17-Mar-00 05:27:13 skrev Alan Cox følgende om "Re: Overcomittable memory":
>
>> You also need to pick a number to count as 'potentially kernel eaten' which
>> I guess for paranoia sake you'd pick ram size. This means you need to turn
>> it on after boot so you can actually set up swap to run anything.
>
> Not necessary. Just take into account the amount used by the kernel at
>the time of the allocation attemp. To the process asking for memory, it
>makes no difference who has already allocated memory on the system. All it
>needs to know is if it got it, and if so, where it is.

In other words, you leave the kernel allocating its own memory on
demand?

> In how many ways can a program allocate memory? The ones that come to my
>mind right now are (s)brk(), mmap(), fork(), exec() and stack. Are there
>more?

Or populating a sparse matrix in memory. How would you implement this
without overcommit/demand-allocation??

> The kernel reserves some memory for kernel use. For example the first
>number from /proc/sys/vm/freepages. Are there more cases? Perhaps a minimum
>number disk block buffer/cache pages?

Yes, it keeps odd chunks of RAM and VM free for itself. Not enough to
guarantee any arbitrary operation would succeed without allocating
more, though - and why should it?

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:30 EST