On Tue, Sep 1, 2009 at 12:33 PM, Korey Sewell <[email protected]> wrote:
> 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. > > Well, in exitFunc(), it checks the number of running contexts (process->system->numRunningContexts()) and schedules an exit event with the Simulator only if that number is 1. Otherwise, it just halts the thread (tc->halt()). In exitGroupFunc(), currently, it just schedules an exit event with the Simulator. > 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. > Yes, I decided to illustrate the problem using the 2T-hello-gzip example particularly because of the gross imbalance in these workloads. I understand that we would not use such a workload to study SMT behavior. > (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. > > So, in SE mode, is there a distinction made between two threads (workloads) belonging to the same process and two threads belonging to different processes? In other words, if I were to spawn two threads from a single program, would it be possible to run them as two different h/w threads in SE mode? -Soumyaroop. > 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 > > -- Soumyaroop Roy Ph.D. Candidate Department of Computer Science and Engineering University of South Florida, Tampa http://www.csee.usf.edu/~sroy
_______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
