From: Ralf Baechle <ralf@oss.sgi.com>
To: "Kevin D. Kissell" <kevink@mips.com>
Cc: linux-mips@oss.sgi.com
Subject: Re: Sigcontext->sc_pc Passed to User
Date: Fri, 12 Jul 2002 12:00:24 +0200 [thread overview]
Message-ID: <20020712120024.A20727@dea.linux-mips.net> (raw)
In-Reply-To: <003301c2297a$380ed400$10eca8c0@grendel>; from kevink@mips.com on Fri, Jul 12, 2002 at 10:00:27AM +0200
On Fri, Jul 12, 2002 at 10:00:27AM +0200, Kevin D. Kissell wrote:
> The IRIX team made some stunningly bad design
> decisions over the years, my favorite being "virtual
> swap space" and its side effect of deliberately killing
> system daemons at random under load. A signal scheme
> such as we have now in MIPS/Linux, where a user program
> *cannot* identify the instruction causing a signal if
> that instruction was in the delay slot of a taken branch,
> is broken from first principles.
Certainly you're right when you say a signal handler show know which
instruction was causing a fault. Ours is simply a too bad implementation
of their interface ...
IRIX virtual swap space is simply memory overcommit. Linux has that too
and it's been subject to frequent religious discussions on Linux kernel.
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.
Ralf
next prev parent reply other threads:[~2002-07-12 9:56 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 [this message]
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
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=20020712120024.A20727@dea.linux-mips.net \
--to=ralf@oss.sgi.com \
--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.