Linux MIPS Architecture development
 help / color / mirror / Atom feed
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

  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