On Fri, 17 Mar 2000 10:52:55 -0600 (CST), you wrote:
>"Alan Curry" <pacman-kernel@cqc.com>:
>> James Sutherland writes the following:
>> >
>> >On 15 Mar 2000, Rask Ingemann Lambertsen wrote:
>> >> Not at all. COW is a performance optimisation which does not depend on
>> >> overcommitment of memory in any way. Why would you want to turn it off?
>> >
>> >Because it *IS* overcommitment of memory. You can have two processes, each
>> >with their 200Mb of data, in a machine with 256Mb RAM+swap, quite happily
>> >- until they start writing to it, at which point you discover you have
>> >overcommitted your memory, and things go wrong.
>>
>> Just because you can describe an example scenario in which COW and
>> overcommit are both used, does not mean that they are inseparable. You can do
>> COW by simply *reserving* RAM or swap space at fork() time and copying data
>> into it later. That is COW without overcommit.
>>
>> Unfortunately nobody with the necessary skills seems interested in
>> implementing it that way.
>
>Just doing this does force the administrator to give a very large amount
>of swap space to the system. Currently, there is no way to tell fork not
>to make such reservations (but only sometimes...). If the desired sequence
>is fork()/exec() then the fork doesn't have to reserve anything more than
>some stack space (and only one or two pages at that). Anything else
>causes/permits the OOM condition.
No. Allocating memory causes OOM conditions. Disabling overcommit just
moves the allocation from being on-demand (allocate VM when the
address space is used) to being on-request (allocate it when the
address space is allocated).
>I wonder if it could be coded as
> fork() --- reserve one or two pages for anticipated fork.
> on next page fault or syscall -- If page fault or non-exec syscall,
> reserve the entire worst case memory amount.
> If syscall is exec then allocate/reserve memory for the
> new image.
>
>The pagefault must be a COW page that is not one of the already reserved
>stack pages for the fork...
All this does is inflate the memory usage of the process early on.
>An alternative would be to reserve (say) 10 pages. Anytime the new process
>exceeds this reserved amount (via COW) the entire process size must be reserved.
>If this exceeds the users resource limit, then the process is aborted and
>the parent process recieves the child termination signal of OOM (either
>a per user resource limit signal or a system signal.
>If an exec system call is called first, then the new process starts with
>the reserve allocation for the new image.
>
>Memory allocation (via sbrk or whatever) would always reserve the additional
>memory allocated (or free reserved memory if deallocating, even though noone
>does that).
>
>On second thought - I like the alternative better:
>a. It requires no coding change in applications
>b. It should be relatively straight forward implementation
>c. transparent to users, except when they run out of virtual memory.
Why not just allocate the memory on-demand? If the process then
becomes too big, you terminate it. Otherwise, it's fine.
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:27 EST