linux-mips
[Top] [All Lists]

Re: Sigcontext->sc_pc Passed to User

To: "Kevin D. Kissell" <kevink@mips.com>
Subject: Re: Sigcontext->sc_pc Passed to User
From: Ralf Baechle <ralf@oss.sgi.com>
Date: Fri, 12 Jul 2002 12:00:24 +0200
Cc: linux-mips@oss.sgi.com
In-reply-to: <003301c2297a$380ed400$10eca8c0@grendel>; from kevink@mips.com on Fri, Jul 12, 2002 at 10:00:27AM +0200
References: <00b401c228ba$88b29bf0$10eca8c0@grendel> <20020712034015.C16608@dea.linux-mips.net> <003301c2297a$380ed400$10eca8c0@grendel>
Sender: owner-linux-mips@oss.sgi.com
User-agent: Mutt/1.2.5.1i
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


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