From: Ralf Baechle <ralf@oss.sgi.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: "Kevin D. Kissell" <kevink@mips.com>, linux-mips@oss.sgi.com
Subject: Re: Sigcontext->sc_pc Passed to User
Date: Fri, 12 Jul 2002 16:23:22 +0200 [thread overview]
Message-ID: <20020712162322.A18691@dea.linux-mips.net> (raw)
In-Reply-To: <E17T03Y-0002tg-00@the-village.bc.nu>; from alan@lxorguk.ukuu.org.uk on Fri, Jul 12, 2002 at 02:01:56PM +0100
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.
Ralf
next prev parent reply other threads:[~2002-07-12 14:19 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-07-11 9:08 Sigcontext->sc_pc Passed to User Kevin D. Kissell
2002-07-11 9:08 ` Kevin D. Kissell
2002-07-11 13:17 ` Maciej W. Rozycki
2002-07-11 15:16 ` Kevin D. Kissell
2002-07-11 15:16 ` Kevin D. Kissell
2002-07-11 16:52 ` Maciej W. Rozycki
2002-07-12 1:40 ` Ralf Baechle
2002-07-12 8:00 ` Kevin D. Kissell
2002-07-12 8:00 ` Kevin D. Kissell
2002-07-12 10:00 ` Ralf Baechle
2002-07-12 11:49 ` Kevin D. Kissell
2002-07-12 11:49 ` Kevin D. Kissell
2002-07-12 15:29 ` Ralf Baechle
2002-07-12 13:01 ` Alan Cox
2002-07-12 13:01 ` Alan Cox
2002-07-12 14:23 ` Ralf Baechle [this message]
2002-07-12 15:36 ` Alan Cox
2002-07-12 15:36 ` Alan Cox
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20020712162322.A18691@dea.linux-mips.net \
--to=ralf@oss.sgi.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=kevink@mips.com \
--cc=linux-mips@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox