[Top] [All Lists]

Re: Sigcontext->sc_pc Passed to User

To: Alan Cox <>
Subject: Re: Sigcontext->sc_pc Passed to User
From: Ralf Baechle <>
Date: Fri, 12 Jul 2002 16:23:22 +0200
Cc: "Kevin D. Kissell" <>,
In-reply-to: <>; from on Fri, Jul 12, 2002 at 02:01:56PM +0100
References: <> <>
User-agent: Mutt/
On Fri, Jul 12, 2002 at 02:01:56PM +0100, Alan Cox wrote:

> > Non-overcommit means large amounts of memory are required when forking
> > of a new process.  The standard example is a fat bloated Mozilla forking
> > for printing.  Non-overcommit means you need those 50 or 100 megs of
> > Mozilla process size once more and if not as physical memory then at
> > least as swap space.  Deciede yourself if you're paranoid and want that
> > operation to only succeed if that much memory is actually available or
> > if you take the risk of the fork & exec operation failing the other way.
> Your numbers are ridiculously off.
> A mozilla instance on x86 commits 17Mb of potentially swap backed memory
> when viewing the mozilla 1.0 start page. (Its actually a bit less but there
> is delay in the garbage collector)

These were typical numbers of the last Mozilla I hacked myself on MIPS.
It can grow larger without doing alot.  Aside of that this isn't Mozilla
specific; any arbitrary program that does some fork & exec thing and
it's memory size could be choosen.

> 2.4.18/19-ac support non overcommit, and its rather useful

No doubt about that.  I just say non overcommit has been subject to long
discussions and as usually in such religious discussions both sides had
valid arguments.  I leave it to everybody to choose his / her own poison.


<Prev in Thread] Current Thread [Next in Thread>