All of lore.kernel.org
 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

  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.