Re: [Qemu-devel] [PATCH] fix possible NULL pointer use in hw/ptimer.c

[Rob Landley <rob@landley.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.  Returning nonzero doesn't mean you have enough
> > memory, because it's given you a redundant copy on write mapping of the
> > zero page and will fault in physical pages when you write to 'em, which
> > has _no_ return value.  Instead, the out of memory killer will shoot 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 mode,
> which is often but not always the default.

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

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

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

> Paul

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