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
