In addition to what Steve said in the subsequent email, you want to verify for yourself what happens in "exit" / "exit_group" system calls get called in syscall_emul.cc.
More than likely, the literal "exit" function gets called and stop the simulation. There are a couple of side issues: (1) Is running the all the workloads to completion the desired behavior for a SMT study? Note that in most cases you'll want to see the effect on the system when workloads are running simultaneously. However, if you continue a workload to completion, then you may distort the results since no 2 workloads are generally the exact same length. In the case of a 2T-hello-gzip, you have the dramatic case where I would assume that all the characteristics of the gzip workload will reflect the stats since it so heavily subsumes the hello workload. Of usage to you may be sim options like "max_insts_any_thread" or "max_insts_all_threads" (similar to max tick) so that you can make a fair comparison across all threads and view system output. Of course, the desired behavior is subjective to your study but these are just things to note. (2) Briefly, we did check to see which threads were running before stopping simulation in M5. However, it was taken out as that implementation was a little too intrusive into the CPU model. I believe the preferred solution would be (as Steve said) to check all the threads belong to that process in the syscall_emul.cc file (?) and then call the haltContext/deactivateContext/___Context (?) to all the CPUs that have those same processes so that only those threads in the same process stop executing. On Tue, Sep 1, 2009 at 11:51 AM, soumyaroop roy <[email protected]> wrote: > Oh, that is correct, Steve! > > Ok, so here's the problem: > If I were to run an SMT configuration, say, 2T-hello-gzip (both compiled > with gcc 4.3.2 built with linux kernel 2.6.X) as two workloads on a single > processor using O3 or inorder, when "hello" finishes, it kills off gzip too. > I figured that this happens because the workloads make syscalls to > exit_group instead of exit. This behavior is different for the "hello" > binary distributed with M5 because it does NOT make a syscall to exit_group > but makes a call to exit. > > regards, > Soumyaroop. > > > On Tue, Sep 1, 2009 at 11:39 AM, Steve Reinhardt <[email protected]> wrote: > >> What exactly is the problem that you're encountering? >> >> Note that syscall emulation only occurs in SE mode (that's what the SE >> stands for). The file syscall_emul.cc doesn't even get compiled if >> FULL_SYSTEM is defined. >> >> Steve >> >> On Mon, Aug 31, 2009 at 1:20 PM, soumyaroop roy<[email protected]> wrote: >> > Hello evebody, >> > >> > Here's a small observation that I made: >> > In SMT configurations for ALPHA/Linux, the first workload that finishes >> > terminates all the other workloads on the CPU because it makes the >> system >> > call, exit_group(). This problem, however, does not surface with the >> "hello" >> > binary checked into the repository because, I think, it is compiled with >> an >> > older compiler toolchain (which was build with linux 2.4.3) and it makes >> a >> > call to exit() instead of exit_group(). >> > >> > So my question is: >> > Shouldn't the exit_group() syscall be simulated by the exit() syscall in >> SE >> > mode? Here is the diff in the source: >> > >> > diff -r e0c1c6d87649 src/sim/syscall_emul.cc >> > --- a/src/sim/syscall_emul.cc Sun Aug 23 14:19:14 2009 -0700 >> > +++ b/src/sim/syscall_emul.cc Mon Aug 31 16:18:05 2009 -0400 >> > @@ -110,12 +110,16 @@ >> > exitGroupFunc(SyscallDesc *desc, int callnum, LiveProcess *process, >> > ThreadContext *tc) >> > { >> > +#if !FULL_SYSTEM >> > + return exitFunc(desc, callnum, process, tc); >> > +#else >> > // really should just halt all thread contexts belonging to this >> > // process in case there's another process running... >> > exitSimLoop("target called exit()", >> > process->getSyscallArg(tc, 0) & 0xff); >> > >> > return 1; >> > +#endif >> > } >> > >> > regards, >> > Soumyaroop. >> > >> > -- >> > Soumyaroop Roy >> > Ph.D. Candidate >> > Department of Computer Science and Engineering >> > University of South Florida, Tampa >> > http://www.csee.usf.edu/~sroy <http://www.csee.usf.edu/%7Esroy> >> > _______________________________________________ >> > m5-dev mailing list >> > [email protected] >> > http://m5sim.org/mailman/listinfo/m5-dev >> > >> > >> _______________________________________________ >> m5-dev mailing list >> [email protected] >> http://m5sim.org/mailman/listinfo/m5-dev >> > > > > -- > Soumyaroop Roy > Ph.D. Candidate > Department of Computer Science and Engineering > University of South Florida, Tampa > http://www.csee.usf.edu/~sroy <http://www.csee.usf.edu/%7Esroy> > > _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev > > -- - Korey
_______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
