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.marss86.org
> > Marss86-Devel mailing listMarss86-Devel <at>
> cs.binghamton.eduhttps://
> www.cs.binghamton.edu/mailman/listinfo/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
