Thanks, I am interested in the multiprocessor configuration in syscall emulation mode. It seems that it should still work in the multiprocessor configuration if all processors are being flushed.
Since the Sampler::signalSwitched won't execute until all processors have called this (meaning that all processors have been flushed), then all memory references should have been completed. No? jeff -----Original Message----- >From: Steve Reinhardt <[EMAIL PROTECTED]> >Sent: Jan 24, 2006 11:45 AM >To: Jeff <[EMAIL PROTECTED]> >Cc: [email protected] >Subject: Re: [m5sim-users] correctly flushing the FullCPU pipeline > > >This sounds to me like it should work, at least for a uniprocessor in >syscall-emulation mode. The only things that could cause other >outstanding memory references would be other processors in a >multiprocessor or I/O devices in full-system mode. > >Steve > >Jeff wrote: >> Hi, >> >> I am flushing the pipeline and it seems to be working most of the time, but >> was wondering if this seems correct. >> >> At the point I want to flush the pipeline, I generate a new event (called >> flushEvent). this subsequently calls a new tick function called >> (flush_tick). basically flush_tick is identical to tick, except the >> fetch() call is commented out. >> And at the end of the call, if no events have been scheduled I check the IQs >> and LSQs to see if any instructions remain. If instructions still exist in >> either queue I generate another flushEvent. If there are no more >> instructions, I generate a different event called (lastFlushEvent). this >> event subsequently calls a different function notifying me that the pipeline >> has been flushed completely. I'm not sure if this is right though. Is it >> possible for outstanding memory references to exist? >> >> thanks, >> jeff >> >> -----Original Message----- >>> From: Steve Reinhardt <[EMAIL PROTECTED]> >>> Sent: Jan 20, 2006 5:04 PM >>> To: James Srinivasan <[EMAIL PROTECTED]> >>> Cc: Jeff <[EMAIL PROTECTED]>, [email protected] >>> Subject: Re: [m5sim-users] Sampler in ALPHA_SE mode >>> >>> >>> James, >>> >>> Thanks for the post. Everything you said looks correct to me. Your >>> email can now serve as the official documentation on the matter :-). >>> Note that the phase0_cpus and phase1_cpus vectors can have multiple CPUs >>> to allow you to do sampling on a multiprocessor or multi-system >>> configuration. It's also worth repeating (from your earlier mail to the >>> list) that the statistics get reset when you switch, so the final stats >>> only reflect that last phase. (Somebody chime in if you have anything >>> else to add.) >>> >>> Right now our only use of the sampler is for a one-time transition from >>> a SimpleCPU-based warm-up phase to a FullCPU-based measurement phase. >>> The key problem with switching in the other direction is making sure >>> that the CPU and the memory system have reached a steady state (i.e. >>> with no outstanding events that will cause trouble when they get >>> processed after the switchover). We have code in there that takes care >>> of the memory-system side of things (basically stalling the CPU until >>> all outstanding memory transactions complete before transitioning to the >>> non-event mode), but haven't worked on the CPU side of the problem (not >>> that it's necessarily that hard, we just haven't had the need to work on >>> it). If you're interested in doing continuous sampling, it's probably >>> not a huge amount of work to make that happen. >>> >>> Steve >>> >>> James Srinivasan wrote: >>>>> I'm trying to use the Sampler module to switch between functional >>>>> and performance simulation using phase analysis approaches like >>>>> SimPoint (UCSD). I am trying to us the Sampler module in ALPHA_SE >>>>> mode, but am not sure how to write the configuration files. >>>> First off I'm not sure this is supported with the current m5 release. >>>> sampler.cc:167 says: >>>> >>>> //We can't switch back from detailed yet, just finish sampling >>>> //Temporary stop-gap >>>> >>>> when trying to switch from phase1 back to phase0. >>>> >>>> >>>> Since sampling seems to have resulted in some confusion on the list I'll >>>> write up what I've managed to work out so far. To use the sampler you >>>> need to instantiate it like: >>>> >>>> root.sampler = Sampler(phase0_cpus = [root.cpu0], phase1_cpus = >>>> [root.cpu1], periods = [1e7, 2e7]) >>>> >>>> in your config file. The first period tells you how long phase0 will >>>> last, the second period is how long phase1 will last. The intention is >>>> to revert back to phase0 after phase1 but right now the code just exits >>>> simulation cleanly. The critical bit you need to do is ensure the two >>>> CPU models are hooked up to the same memory system and are running the >>>> same workload. The way I'm doing this is by instantiating the memory >>>> items and the workload in the root object as follows: >>>> >>>> root=Root() >>>> root.toL2Bus = ToL2Bus() >>>> root.toMemBus = ToMemBus() >>>> root.dcache = DL1(out_bus=Parent.toL2Bus) >>>> root.icache = IL1(out_bus=Parent.toL2Bus) >>>> root.l2 = L2(in_bus=Parent.toL2Bus, out_bus=Parent.toMemBus) >>>> root.ram = SDRAM(in_bus=Parent.toMemBus) >>>> >>>> I then instantiate the CPU models as: >>>> >>>> root.cpu0 = MySimpleCPU() >>>> root.cpu1 = MyDetailedCPU() >>>> >>>> Inside the definition of MySimpleCPU and MyDetailedCPU (based on >>>> SimpleCPU and DetailedCPU respectively) the icache and >>>> dcache attributes are set to Parent.icache and Parent.dcache >>>> >>>> I then instantiate the sampler as above. Finally I instantiate the >>>> workload: >>>> >>>> bm = Benchmarks.GzipSource() >>>> root.cpu0.workload = bm >>>> root.cpu1.workload = bm >>>> >>>> >>>> I'm not 100% convinced this is the correct way and I might have >>>> forgotten some details but from some quick simulations this morning it >>>> seems ok. Can post my full config files if you like, >>>> >>>> Hope this helps, >>>> >>>> James >>>> >>>> >>> >>> ------------------------------------------------------- >>> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files >>> for problems? Stop! Download the new AJAX search engine that makes >>> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! >>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 >>> _______________________________________________ >>> m5sim-users mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/m5sim-users >> >> >> >> ------------------------------------------------------- >> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files >> for problems? Stop! Download the new AJAX search engine that makes >> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! >> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 >> _______________________________________________ >> m5sim-users mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/m5sim-users > > >------------------------------------------------------- >This SF.net email is sponsored by: Splunk Inc. Do you grep through log files >for problems? Stop! Download the new AJAX search engine that makes >searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! >http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 >_______________________________________________ >m5sim-users mailing list >[email protected] >https://lists.sourceforge.net/lists/listinfo/m5sim-users ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 _______________________________________________ m5sim-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/m5sim-users
