Just for reference, here's the menu.lst entry from my menu.lst: title Ubuntu 9.04, kernel 2.6.31.4qemu uuid ab838715-9cb7-4299-96f7-459437993bde kernel /boot/vmlinuz-2.6.31.4qemu root=/dev/hda1 ro single 1 rootdelay=200
Everything look OK here? On Wed, Mar 13, 2013 at 11:49 AM, Paul Rosenfeld <[email protected]>wrote: > 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
