Matija Nalis wrote:
>
> On 17 Mar 2000 00:27:42 +0100, Rask Ingemann Lambertsen <rask-linux@kampsax.k-net.dk> wrote:
> >Den 15-Mar-00 11:49:45 skrev James Sutherland følgende om "Re: Overcommitable memory??":
> >> On Wed, 15 Mar 2000, David Whysong wrote:
> >
> >>> The only possibilities are to (a) enforce hard memory limits with no
> >>> overcommit, thereby wasting large amounts of swap space that will never
> >>> get used while not really solving the problem,
> >
> >> As well as *destroying* performance (you'd effectively eliminate COW
> >> capability on fork - if your 500Mb simulation wants to fork a 100k mailer
> >> process to send you an update, the kernel has to allocate and copy 500Mb
> >> of RAM/swap first, then discard it all again.)
> >
> > 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?
>
> Say you have 800MB virtual RAM, and you simulation currently uses 500MB.
> And now, it tries to fork(2). Do you allow it, or does fork fail with
> -ENOMEM ?
---
Had exactly this problem in SoftWindows on IRIX. It would
fork to run some trivial external application, or a sound-process.
It would die running out of memory (SWin mem image was often large).
Solution was to convert to using
'sproc', where amount of process sharing can be user defined -- something
like a heavy-weight thread. If all you were going to do was to exec
another proc, you could set the new proc to "share all mem":
PR_SADDR All virtual space attributes (shared memory, mapped files, data
space) are shared. If one process in a share group attaches to
a shared memory segment, all processes in the group can access
that segment.
==
Then do the exec call. Thus no overcommit.
-l
--
Linda A Walsh | Trust Technology, Core Linux, SGI
law@sgi.com | Voice: (650) 933-5338
-
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:25 EST