qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] Permit zero-sized qemu_malloc() & friends


From: malc
Subject: Re: [Qemu-devel] [PATCH] Permit zero-sized qemu_malloc() & friends
Date: Sun, 6 Dec 2009 20:45:44 +0300 (MSK)

On Sun, 6 Dec 2009, Avi Kivity wrote:

> On 12/06/2009 06:52 PM, Ian Molton wrote:
> > Markus Armbruster wrote:
> > 
> >    
> > >      p = malloc(n * sizeof(struct foo);
> > >      if (n&&  !p)
> > >          exit_no_mem();
> > >      for (i = 0; i<  n; i++)
> > >          compute_one(p, i);
> > > 
> > > With qemu_malloc(), the error handling moves into qemu_malloc():
> > > 
> > >      p = qemu_malloc(n * sizeof(struct foo);
> > >      for (i = 0; i<  n; i++)
> > >          compute_one(p, i);
> > >      
> > And you lose the ability to fail gracefully...
> >    
> 
> We never had it.  Suppose p is allocated in response to an SCSI register
> write, and we allocate a scatter-gather list.  What do you do if you OOM?

Uh, please do not generalize.

See for instance 29ddf27b72960d6e6b115cd69812c9c57b2a7b13 the incident was
logged and debugged, no OOM, no abort. Not all scenarios admit this, but
claiming that there are none that do is incorrect.

> 
> 1) Introduce an error path that works synchronously off the stack and so does
> not need to allocate memory
> 2) Don't allocate in the first place, always read guest memory and transform
> it for sglists, preallocate everything else
> 3) Have a per-thread emergency pool, stall the vcpu until all memory is
> returned to the emergency pool
> 
> all of these options are pretty horrible, either to the code or to the guest,
> for something that never happens.
> 
> 

-- 
mailto:address@hidden




reply via email to

[Prev in Thread] Current Thread [Next in Thread]