From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1JAz45-0003lk-E3
	for qemu-devel@nongnu.org; Fri, 04 Jan 2008 21:47:13 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1JAz3z-0003du-UW
	for qemu-devel@nongnu.org; Fri, 04 Jan 2008 21:47:12 -0500
Received: from [199.232.76.173] (helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1JAz3z-0003df-Bm
	for qemu-devel@nongnu.org; Fri, 04 Jan 2008 21:47:07 -0500
Received: from static-71-162-243-5.phlapa.fios.verizon.net ([71.162.243.5]
	helo=grelber.thyrsus.com)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <rob@landley.net>) id 1JAz3z-0007aL-62
	for qemu-devel@nongnu.org; Fri, 04 Jan 2008 21:47:07 -0500
From: Rob Landley <rob@landley.net>
Subject: Re: [Qemu-devel] [PATCH] fix possible NULL pointer use in hw/ptimer.c
Date: Fri, 4 Jan 2008 20:47:02 -0600
References: <477C489C.1000208@earthlink.net>
	<200801041844.43789.rob@landley.net>
	<200801050107.59131.paul@codesourcery.com>
In-Reply-To: <200801050107.59131.paul@codesourcery.com>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Disposition: inline
Message-Id: <200801042047.03059.rob@landley.net>
Content-Transfer-Encoding: quoted-printable
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Paul Brook <paul@codesourcery.com>
Cc: Markus Hitter <mah@jump-ing.de>, qemu-devel@nongnu.org, Robert Reif <reif@earthlink.net>

On Friday 04 January 2008 19:07:58 Paul Brook wrote:
> > On modern operating systems, allocations only return zero when you
> > exhaust virtual memory. =A0Returning nonzero doesn't mean you have en=
ough
> > memory, because it's given you a redundant copy on write mapping of t=
he
> > zero page and will fault in physical pages when you write to 'em, whi=
ch
> > has _no_ return value. =A0Instead, the out of memory killer will shoo=
t your
> > program in the head in the middle of it's run
>
> Decent operating systems allow the system administrator gets to choose =
how
> optimistic memory allocation is. You're describing wildly-optimistic mo=
de,
> which is often but not always the default.

True, but if you completely disable overcommit then fork() a large proces=
s and=20
exec() a small one, you haven't got enough memory even though you're not=20
really _using_ any to do so.

You can disable overcommit and give the system an egregious amount of swa=
p=20
space, but then your pathological case is the system going into swap=20
thrashing la-la land and essentially freezing (advancing at 0.1% of its=20
normal rate, if that, for _hours_) instead of killing some runaway proces=
ses=20
(or rebooting) and recovering.  Not necessarily and improvement, especial=
ly=20
if you're the one with the pager.

It is alas, not a simple problem to get right.  fork() and exec() being=20
separate system calls isn't always an improvement over a combined one. =20
(Espeically since exec() needs a file, not a file handle.  You can't re-e=
xec=20
your current process unless you can find and reopen it, you can't exec() =
from=20
a pipe...  And then there's nommu vfork(), always fun...)

> Paul

Rob
--=20
"One of my most productive days was throwing away 1000 lines of code."
  - Ken Thompson.