qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] memory: add -dont-dump-guest option to reduce c


From: Jason Baron
Subject: Re: [Qemu-devel] [PATCH] memory: add -dont-dump-guest option to reduce core dump size
Date: Fri, 6 Jul 2012 16:26:29 -0400
User-agent: Mutt/1.5.20 (2009-12-10)

On Thu, Jul 05, 2012 at 09:04:18PM -0300, Marcelo Tosatti wrote:
> On Mon, May 21, 2012 at 01:53:36PM -0400, Jason Baron wrote:
> > On Fri, May 04, 2012 at 05:23:51PM -0400, Jason Baron wrote:
> > > Add a command line parameter to not dump guest memory in the core dump, 
> > > the
> > > command line is: -dont-dump-guest. This brought the core dump down from
> > > 383MB to 13 MB on a 1GB guest.
> > > 
> > > Signed-off-by: Jason Baron <address@hidden>
> > > ---
> > >  exec.c          |   13 +++++++++++++
> > >  osdep.h         |    7 +++++++
> > >  qemu-options.hx |    5 +++++
> > >  sysemu.h        |    1 +
> > >  vl.c            |    4 ++++
> > >  5 files changed, 30 insertions(+), 0 deletions(-)
> > > 
> > 
> > Any thoughts on this? Is the guest memory often helpful in debugging
> > when the qemu process segfaults?
> 
> For most development related usage, no (with large guests, its 
> troublesome).
> 
> Please add documentation for the command (patch looks fine otherwise).
> 
> > This feature also seems useful if somebody is running a sensitive
> > workload, such that the non-sensitive qemu state can be dumped
> > independently of the guest state. In that case, perhaps there should
> > also be an option that allows the guest to be dumped on a segfault, now
> > separately?
> 
> Isnt what this option does? (well, disabling it).
> 

Right, disabling it gives us both qemu and guest bits. So I was just
suggesting a mode that dumps guest bits but not qemu bits. (Probably
that is setup in guest, though). So I'm not sure if that makes sense.
But as Markus suggested, if we make the interface more general, we are
more open to something like that later (at least in terms of the
interface).

Thanks,

-Jason



reply via email to

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