Now i get it, you can use serial port to send kill signal to mcf. So boot os with serial port enabled and create checkpoint by your method. Then use serial port to send the kill signal. Remember one thing, serial port do require to login, so login to serial port before you create checkpoint. You can use Ctrl+Alt+3 to switch to serial port or use pty inteface.
- Avadh On Wednesday, June 8, 2011, Zhe Wang <[email protected]> wrote: > Hi, avadh, > > The way I create checkpoint for two benchmarks running on different cores is: > > > cd /root/mcf > taskset 0x1 ./create_checkpoint mcf & > cd /root/milc > taskset 0x2 milc; ~/stop_sim > > So it create a checkpoint for mcf, but since mcf and milc run at the same > time but different cores, so this checkpoint for both mcf and milc. When I > load checkpoint mcf and run the simulation, there are two thread running that > is thead mcf running on core0 and thread milc running on core1. What I want > to do is kill thread mcf just left thread milc running. So any idea about > this? > > Thank you > zhe > > > On Wed, Jun 8, 2011 at 3:59 PM, avadh patel <[email protected]> wrote: > You can do following: > > 1. Boot a new qemu image with serial interfsce forwarded to a pty. > 2. After boot create a checkpoint. > 3. Write a script that start the marss from that checkpoint and > connect to the serial port via pty connection and send simulation > command. > Here you can either run both benchmarks or just one. > > Take a look at create_checkpoint.py and run_bench.py script for > example on how to use serial port. > > - Avadh > > On Wednesday, June 8, 2011, DRAM Ninjas <[email protected]> wrote: >> Are you using ./start_sim to launch the simulation or are you using an >> embedded call to ptlcall_switch_to_sim()? What about doing something really >> whacky like >> resume from checkpointsleep(1) >> generate a random number (seeded on the time) -- or perhaps read a byte from >> /dev/urandom (not sure what a VM uses as an entropy pool though)with 50% >> probability, pkill -9 milc (or an equivalent C call if you're using ptlcalls) >> >> I wonder if there's just enough jitter in the time to cause the random >> number to produce a different number of different checkpoint starts ... >> >> >> >> On Wed, Jun 8, 2011 at 2:01 PM, Zhe Wang <[email protected]> wrote: >> >> Hi, paul, >> >> Yes, it just set up a second hard drive image with a checkpoint just >> launches milc alone, the difference from bootup is nondeterministic and >> definitely mess up the result. So I have to figure out how to >> kill thread right after it starts to run. >> >> Thanks >> zhe >> >> On Wed, Jun 8, 2011 at 11:16 AM, DRAM Ninjas <[email protected]> wrote: >> I don't think you're going to be able to do this very easily since by >> definition the checkpoint will always have identical state between boot ups, >> so I'm not sure how you'd send a message to the machine to tell it you want >> to kill the thread. Perhaps if you rigged up some crazy network code like >> "query the host machine and see if I need to abort", though getting that to >> work with QEMU networking would probably be a fun fun task (and would also >> pollute your results, probably). >> >> >> >> Why don't you just setup a second hard drive image with a checkpoint that >> just launches milc alone? Are you worried about the differences from the >> bootup being nondeterministic and messing up your results? >> >> On Wed, Jun 8, 2011 at 9:47 AM, Zhe Wang <[email protected]> wrote: >> >> Hi, >> >> I have a question about how to kill a thread after marss load a checkpoint. >> I made a checkpoint for multiprogram application. Such as I have two >> benchmark mcf and milc. I set them on two different cores and run them by >> using marss. After I load the checkpoint , I would like to kill benchmark >> mcf, just left milc running. Then reason I want to do this is I would like >> to compare the performance difference between benchmark milc running alone >> with milc running with other benchmarks. Any idea about how to kill a >> thread after load the checkpoint? >> >> Thanks >> zhe >> >> _______________________________________________ >> 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
