Nope, nothing fancy. A few commits behind HEAD on master with some modifications to the simulation (but nothing changed in qemu). Added rootdelay=200 and it hangs right after freeing kernel memory and takes a really long time to get the disks mounted and the devices loaded.
I'll double check my image to make sure that the rootdelay made it into the correct menu.lst entry. The odd thing is that once I get to the login prompt (if I'm doing an interactive session), qemu is perfectly responsive. Maybe I'll try to boot a raw image instead of qcow2 to see if that changes anything. On Wed, Mar 13, 2013 at 11:43 AM, <[email protected]> wrote: > 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
