Once you create a checkpoint, restore using -drive cache=writeback,file=YOUR_DISK_IMAGE option to load the benchmarks faster.
- Avadh On Thu, May 19, 2011 at 5:34 PM, <[email protected]> wrote: > Yes, Checkpoints in QEMU 0.14 are very slow. I was thinking of > getting a fresh copy of Disk and do this process, if it helps. > > --ishwar > ---- Original message ---- > >Date: Thu, 19 May 2011 17:13:49 -0700 > >From: avadh patel <[email protected]> > >Subject: Re: [marss86-devel] Disk Image and checkpoint issues > >To: Saurabh Gupta <[email protected]> > >Cc: <[email protected]> > > > > On Thu, May 19, 2011 at 4:58 PM, Saurabh Gupta > > <[email protected]> wrote: > > > > avadh patel <avadh4all <at> gmail.com> writes: > > > > > > > > > > > On Thu, May 19, 2011 at 10:51 AM, Saurabh Gupta > > <saurabg <at> gmail.com> > > wrote: > > > > > > Hi, > > > I have created the checkpoints for different > > benchmarks using > > > create_checkpoints.py. I do not want to run the > > benchmarks from > > > the beginning like the script given on github > > does. I let the > > > benchmark run for a while and then call > > create_checkpoint to > > > save the state of machine(VM running the > > benchmark). Now I > > > start the simulation by run_bench.py. I have > > couple of concerns > > > here: > > > 1. I use -kill-after-finish in qemu > > configuration input, so I > > > am worried if the disk image gets corrupted by > > that. I get > > > varied results if I run the same checkpoint > > again and again > > > from the same image. The variation is less when > > I use my backup > > > disk image with checkpoints in it every time I > > run it. > > > > > > Disks corruption depends on the type of > > benchmarks. If you are running > > > something that uses disk too much ('dedup' for > > example) then there > > > is a high chance that you'll get disk > > corruption. To avoid this best way > > > > > > to run these benchmarks is to use it like > > following: > > > > > > $ ./your_benchmark; ./kill_sim > > > > > > In this way the simulation will be killed after > > it completes the benchmark. > > > > > > There is some option in qemu to start in > > 'read-only' mode where changes > > > to the disk are saved into some tmp file but I > > never got that working for me. > > > May be new 0.14 merge might work. > > > > > > > > > > > > 2. Is that correct that run_bench.py is running > > all the benchmarks > > > checkpoints at the same time? Sometimes I get > > results for all the > > > benchmarks, sometimes some of them do not > > finish, sometimes they > > > would finish but their stats file is corrupted. > > > > > > run_bench.py spawn the number of simulations in > > parallel as number of > > > disk images you provided in 'qemu_img' variable. > > > > > > About stats file corruption, there has been > > couple of small bug fixes in > > > > > > master branch about it, so update your code if > > you haven't. > > > > > > - Avadh > > > > > > > > > > > > > > > I am seeing all this weird behavior, has anyone > > else seen this? > > > or if someone can point out where I am going > > wrong? > > > Thanks. > > > -Saurabh > > > > > > _______________________________________________http://www.mars > s86.org > > > Marss86-Devel mailing listMarss86-Devel <at> > > > cs.binghamton.eduhttps://www.cs.binghamton.edu/mailman/listinf > o/marss86-devel > > > > > > > > > > > > > > > > Hi, > > > > Thanks for the suggestions, but I am confused now > > about the statement you > > made saying "run_bench.py spawn the number of > > simulations in parallel as > > number of disk images you provided in 'qemu_img' > > variable." > > > > I think create_checkpoint.py creates all the > > checkpoints in the same disk > > image. Are you suggesting to have only one > > checkpoint to be created in one > > disk image for these purposes? > > > > I have my all 10 benchmark checkpoints in the same > > image and I provide > > the path of this image to run_bench.py. It > > launches all the simulations > > at once from that. Do you think this is where I am > > going wrong? Because > > now all the simulations try to access the same > > image and modify it while > > it runs, leading to the behavior I am seeing right > > now. > > > > in run_bench.py, 'qemu_img' is a variable that holds > > a list of images that contains > > all of your benchmark snapshots. Basically I copy a > > single image multiple times and > > put all these image names into this list to run > > benchmarks in parallel. If there is only > > one disk image name in 'qemu_img' then it will run > > all benchmarks in sequence. > > In case of only single disk image, it will run > > benchmarks in sequence and it won't > > corrupt the image. > > - Avadh > > P.S. Is anyone having issues with loadvm or savevm > > being 'too-slow' in qemu-0.14? > > > > > > -Saurabh > > > > _______________________________________________ > > http://www.marss86.org > > Marss86-Devel mailing list > > [email protected] > > https://www.cs.binghamton.edu/mailman/listinfo/marss86- > devel > >________________ > >_______________________________________________ > >http://www.marss86.org > >Marss86-Devel mailing list > >[email protected] > >https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel >
_______________________________________________ http://www.marss86.org Marss86-Devel mailing list [email protected] https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel
