I forgot to add -- The only issue that I can see with your approach is keeping qemu in sync with ptlsim. If you look at `ptl_add_phys_memory_mapping` in qemu/cputlb.c, you'll notice that qemu feeds page mappings to ptlsim even when ptlsim isn't active.
I could be wrong here, but I believe you'll need to update that mapping once you boot a checkpoint. We'd be more than willing to help you in whatever way to can to get something like this committed to master. Tyler > Paul, > > Adding rootdelay to menu.lst is the same thing as passing it as a kernel > argument, so yes.... no difference. > > As Avadh mentioned, 5 hours is a _long_ time to get things going. I got a > 16+ core instance to get to a prompt in a few minutes last time I tried. > Admittedly, I never tried to create a checkpoint when I had that many > cores... is the checkpointing taking a long time, or are you waiting that > long just to boot the system? > > What value are you passing to rootdelay? You're building master without > debugging or anything fancy, right? > > Tyler > >> I added rootdelay to menu.lst (and I think in grub1 you don't have to do >> anything else, right?) >> >> I'm using the old parsec images with a reasonably ancient ubuntu. Should >> I >> be using something more recent? >> >> >> >> On Wed, Mar 13, 2013 at 11:13 AM, avadh patel <[email protected]> >> wrote: >> >>> >>> >>> >>> On Tue, Mar 12, 2013 at 1:19 PM, Paul Rosenfeld >>> <[email protected]>wrote: >>> >>>> Hello Everyone, >>>> >>>> It's been a while but I'm starting to use MARSSx86 for simulations >>>> again. >>>> I've been trying to run 16 core simulations and am finding that the >>>> boot >>>> time is very long (~5 hours to make a checkpoint). This makes it quite >>>> frustrating when I accidentally set the wrong parameters inside the >>>> workload or run the wrong workload or any number of other mistakes I >>>> tend >>>> to make. >>>> >>>> Booting 16 core should not take that long. Did you try adding >>> 'rootdelay' option to kernel command line? It significantly improves >>> kernel >>> boot time in QEMU for large number of cores. >>> >>> - Avadh >>> >>> >>>> So I was thinking -- what if I made a post boot but >>>> pre-simulation-switch >>>> checkpoint (i.e., checkpoint but stay in emulation mode). That way, >>>> the >>>> create_checkpoints.py script could just launch the system from the >>>> post-boot snapshot and proceed to launch the workloads which would >>>> have >>>> the >>>> PTL calls that would then make the actual simulation checkpoints. Not >>>> only >>>> would that reduce the time it took to create a lot of checkpoints, but >>>> also >>>> if I screwed up a checkpoint, I could just delete it, boot the >>>> post-boot >>>> snapshot, tweak the workload, and re-checkpoint the simulation. >>>> >>>> I think marss checkpoints piggyback on qemu's snapshot capabilities, >>>> but >>>> is there some downside to this approach here that I'm missing? >>>> >>>> Thanks, >>>> Paul >>>> >>>> _______________________________________________ >>>> 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 > _______________________________________________ http://www.marss86.org Marss86-Devel mailing list [email protected] https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel
