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

Re: [Xen-devel] code read problems


  • To: msun@xxxxxxxxxxxx, wwwwww4187@xxxxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxx, stodden@xxxxxxxxxx
  • From: "Mike Sun" <msun@xxxxxxxxxx>
  • Date: Thu, 28 Feb 2008 15:53:28 -0500
  • Delivery-date: Thu, 28 Feb 2008 12:53:53 -0800
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=T2kBM9WMOxQ9q0xy8Cnnf3IYGLJOxw5ToWN23SQOK8rdIG71J72loZ7T5pAY5+6UwOkbAKlfljz2SR5PyDlXni0/aVco/4bd/LVYNMaV8U99WdCByen5YtaoUK+K+N6O7fIv+P2C4CiijB2zXw+S6nI/V5zIIYr7NzsN/pH1X7U=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

Hi Brendan,

I'd be very interested to see your NSDI paper.  Any way I could get a
pre-print?  We're actually looking ways of using COW memory to improve
the speed of the checkpoints in our research.

Thanks!
Mike

On Thu, Feb 28, 2008 at 1:52 PM, Brendan Cully <brendan@xxxxxxxxx> wrote:
> Nice summary!
>
>  In part 3, you have:
>
>   ? What does that checkpoint flag do ?
>
>  When that flag is set (through xm save -c), the domain resumes
>  operation after the save operation. Normally "save" destroys the
>  domain.
>
>  You might be interested in my presentation at xen summit 4 about
>  checkpointing, which goes into some detail about the save/migration
>  process:
>
>  http://xen.org/files/xensummit_4/talk_Cully.pdf
>
>  Since then we've increased the speed of checkpointing considerably,
>  but the code to do it isn't in Xen yet. We have a paper about it in
>  the next NSDI conference which has the details, if you're interested.
>
>
>
>  On Wednesday, 27 February 2008 at 14:23, Mike Sun wrote:
>  > I've had to trace through the migration code and made the following
>  > notes.  Hope it helps:
>  >
>  > http://msun.bluespot.org/wiki/doku.php?id=xen_migration_notes
>  >
>  > On Wed, Feb 27, 2008 at 4:37 AM, tgh <wwwwww4187@xxxxxxxxxxx> wrote:
>  > > hi
>  > >   thank you for your reply
>  > >   and i read the code of xc_save.c and xc_restore.c, which maybe do the
>  > >  function of VMsaving and VMrestoring, but i wander, if the code of
>  > >  xc_save.c and xc_restore.c is called by some python code or c code
>  > >  during migration or xm save and xm restore or not? the code of xc_save.c
>  > >  is a main function ,and is it called by other program to do migration or
>  > >  not ?
>  > >
>  > >   and in the code of xc_save.c, there seem no notification to the
>  > >  xenstore or devbackend, and how are these VMdevbackends destroyed in the
>  > >  dom0, when migration or save?
>  > >   and in the code of xc_restore.c,there seems to be an existing
>  > >  VMdomain,and the whole data from savefile or from  migration,will load
>  > >  into the VMdomain, is itï  then ,what code call these code of xc_save
>  > >  and xc_restore?  i am confused
>  > >
>  > >  could you help me out
>  > >
>  > >  Thanks in advance
>  > >
>  > >
>  > >  Daniel Stodden åé:
>  > >
>  > >
>  > > > On Tue, 2008-02-26 at 19:22 +0800, tgh wrote:
>  > >  >
>  > >  >> could you reply in english, i could not read your letter
>  > >  >>
>  > >  >
>  > >  > Don't bother. Just an autoreply generated to tell you the guy is on
>  > >  > vacation.
>  > >  >
>  > >  > Regarding your problem: There is not much you can do to get some sort
>  > >  > execution traces enabled automatically. You probably want to enable
>  > >  > debugging when building Xen and the libraries. Then maybe add a couple
>  > >  > of debug-print statements to the code, whereever you see fit.
>  > >  >
>  > >  > I believe migration support in xend and libxc should be understandable
>  > >  > in isolation. The tricky parts are definitely done in C. Last time I
>  > >  > checked, xend mainly performed a single call to the tools and library.
>  > >  >
>  > >  > Also note that random instrumentation of all code executed for
>  > >  > translating and mapping of the domU address space within the 
> hypervisor
>  > >  > would probably soon get more verbose than you asked for, since some of
>  > >  > the functions involved can be called at a comparatively high 
> frequency.
>  > >  >
>  > >  > Rule 1 when digging your way through complex systems: Divide and
>  > >  > Conquer. Division comes first. Understand one thing at a time, 
> starting
>  > >  > at a comparatively high-level, then selectively dig deeper.
>  > >  >
>  > >  > regards,
>  > >  > daniel
>  > >  >
>  > >  >
>  > >  >
>  > >  >> clp@xxxxxxxxxxx åé:
>  > >  >>
>  > >  >>> Vielen Dank fÃr Ihre Nachricht.
>  > >  >>>
>  > >  >>> Ich bin vom 22-02-08 bis 07-03-08 nicht im Hause und werde Ihre
>  > >  >>>
>  > >  >> E-Mail ab dem 10-03-07  bearbeiten.
>  > >  >>
>  > >  >>> In dringenden FÃllen wenden Sie sich bitte an Herrn Fabio LÃdi, er
>  > >  >>>
>  > >  >> wird Ihnen gerne weiterhelfen.
>  > >  >>
>  > >  >>> Sie erreichen Herrn LÃdi unter:
>  > >  >>> Phone +41 61 6666 406
>  > >  >>> E-Mail fl@xxxxxxxxxxx
>  > >  >>>
>  > >  >
>  > >  >
>  > >
>  > >
>  > >
>  > >
>  > > _______________________________________________
>  > >  Xen-devel mailing list
>  > >  Xen-devel@xxxxxxxxxxxxxxxxxxx
>  > >  http://lists.xensource.com/xen-devel
>  > >
>
>  > _______________________________________________
>  > Xen-devel mailing list
>  > Xen-devel@xxxxxxxxxxxxxxxxxxx
>  > http://lists.xensource.com/xen-devel
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.