OK. Here is some detail. At first, I followed this instruction https://docs.google.com/View?id=dfkk59gg_1079rhf4bd5 AND ran splash2 benchmark on m5.opt (Alpha architecture) with --trace-flags=thread option enabled to get trace of threads: ///////////////////////////////////////////////////////////////////// ./build/ALPHA_FS/m5.opt --trace-flags=Ruby *--trace-flags=Thread*--trace-file=memory.trace configs/example/fs.py -n 8 -b fft /////////////////////////////////////////////////////////////////////
To get trace with threads information, I removed the false condition from /src/arch/alpha/linux like what suggested before in M5 maling-list. However, the output thread pids and start_times were obvious incorrect, while thread name was correct. Like follows: ///////////////////////////////////////////////////////////////////// 2288515504500: threadinfo: Currently Executing Thread FFT,* pid 3211264*, *started at: -4398043299840* 2288517642500: threadinfo: Currently Executing Thread swapper, *pid 3211264*, *started at: -4398043299840* 2288589029000: threadinfo: Currently Executing Thread swapper, pid 3211264, started at: -4398043299840 2288592770000: threadinfo: Currently Executing Thread FFT, pid 3211264, started at: -4398043299840 2288772642500: threadinfo: Currently Executing Thread script, pid 3211264, started at: -4398043299840 2288818042500: threadinfo: Currently Executing Thread script, pid 3211264, started at: -4398043299840 ///////////////////////////////////////////////////////////////////// To fix this issue, I made two slightly changes to /src/arch/alpha/linux/threadinfo.hh: ///////////////////////////////////////////////////////////////////// line 106 and line 119: "Addr offset;" -----> "int32_t offset;" ///////////////////////////////////////////////////////////////////// Then I got a much more reasonable trace: ///////////////////////////////////////////////////////////////////// 2288589029000: threadinfo: Currently Executing Thread swapper, pid 0, started at: 0 2288592770000: threadinfo: Currently Executing Thread FFT, pid 813, started at: 2 2288772642500: threadinfo: Currently Executing Thread script, pid 808, started at: 2 2288818042500: threadinfo: Currently Executing Thread script, pid 821, started at: 2 2288840942000: threadinfo: Currently Executing Thread swapper, pid 0, started at: 0 2288883227000: threadinfo: Currently Executing Thread migration/4, pid 15, started at: 0 ///////////////////////////////////////////////////////////////////// I guess /src/arch/mips/linux/threadinfo.hh also needs to be modified in this way. Thanks. Yi Xiang On Thu, Mar 3, 2011 at 8:20 PM, <m5-dev-requ...@m5sim.org> wrote: > Send m5-dev mailing list submissions to > m5-dev@m5sim.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://m5sim.org/mailman/listinfo/m5-dev > or, via email, send a message with subject or body 'help' to > m5-dev-requ...@m5sim.org > > You can reach the person managing the list at > m5-dev-ow...@m5sim.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of m5-dev digest..." > > > Today's Topics: > > 1. Review Request: Ruby: Add stall and wait to MESI CMP > directory (Nilay Vaish) > 2. Re: Review Request: SCons: Add an option to dump the build > vars, and only do that if asked. (Gabe Black) > 3. Re: Review Request: Ruby: Add stall and wait to MESI CMP > directory (Brad Beckmann) > 4. Re: Review Request: Ruby: Add stall and wait to MESI CMP > directory (Nilay Vaish) > 5. Review Request: Mips: MIPS_FS doesn't build currently, so > delete it to avoid confusion. (Gabe Black) > 6. Re: Review Request: Mips: MIPS_FS doesn't build currently, so > delete it to avoid confusion. (Korey Sewell) > 7. A small bug on thread pid and start time. (Yi Xiang) > 8. Re: A small bug on thread pid and start time. (Korey Sewell) > 9. Re: A small bug on thread pid and start time. > (Gabriel Michael Black) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 03 Mar 2011 17:20:38 -0000 > From: "Nilay Vaish" <ni...@cs.wisc.edu> > To: "Nilay Vaish" <ni...@cs.wisc.edu>, "Default" <m5-dev@m5sim.org> > Subject: [m5-dev] Review Request: Ruby: Add stall and wait to MESI CMP > directory > Message-ID: > <20110303172038.<20110303172038.30530.98...@daystrom.m5sim.org><30530.98529> > 30530.98...@daystrom.m5sim.org> > Content-Type: text/plain; charset="utf-8" > > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.m5sim.org/r/330/ > ----------------------------------------------------------- > > Review request for Default. > > > Summary > ------- > > This patch adds the stall and wait on the mandatory queue of L1 cache > controller of the MESI CMP directory protocol. It is intended to be > more of a discussion (so as to improve my understanding). > > > Diffs > ----- > > src/cpu/testers/rubytest/RubyTester.py 92229cb0cee9 > src/mem/protocol/MESI_CMP_directory-L1cache.sm 92229cb0cee9 > > Diff: http://reviews.m5sim.org/r/330/diff > > > Testing > ------- > > The changes have been tested for 16 processors for 40 different random > seeds with number of loads varying from a 1,000,000 - 4,000,000. The only > concern is that I had to change the dead lock threshold in RubyTester.py > which is surprising. > > > Thanks, > > Nilay > > > > ------------------------------ > > Message: 2 > Date: Thu, 03 Mar 2011 11:00:21 -0800 > From: Gabe Black <gbl...@eecs.umich.edu> > To: m5-dev@m5sim.org > Subject: Re: [m5-dev] Review Request: SCons: Add an option to dump the > build vars, and only do that if asked. > Message-ID: <4d6fe545.6070...@eecs.umich.edu> > Content-Type: text/plain; charset=ISO-8859-1 > > Thinking about this more, this opens up space in the build help for more > higher level, well, build help. We could list all the possible > configurations to use, ie. list the files in build_opts. We could list > the possible m5 binaries to build and what each is for. We could talk > about how regressions are worked in. Is there anything other top level > target people would want to use with scons? I think the unit tests are > in there, and having written one recently you'd think I'd remember :-P. > But those need some packaging TLC before they're really useful for > somebody reading help at that level. > > Gabe > > On 03/03/11 02:47, Gabe Black wrote: > > This is mostly an idea I'm entertaining. It makes it a lot easier to see > > the command line option part of the help which scrolls off the screen > > otherwise which is nice, although whether that's a good thing depends on > > whether you think the command line stuff or the variable stuff is more > > important. This also at least partially makes setting our own special > > help message redundant since the default help would include our new > > options. This does highlight them, though, because it leaves out all the > > regular ones. > > > > Gabe > > > > On 03/03/11 02:46, Gabe Black wrote: > >> ----------------------------------------------------------- > >> This is an automatically generated e-mail. To reply, visit: > >> http://reviews.m5sim.org/r/531/ > >> ----------------------------------------------------------- > >> > >> Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and > Nathan Binkert. > >> > >> > >> Summary > >> ------- > >> > >> SCons: Add an option to dump the build vars, and only do that if asked. > >> > >> Being able to inspect the current value of the build variables is very > useful, > >> but if someone is looking for more basic information all that text > obscures > >> the other parts of the help message. This change removes the build > variables > >> from the main help message and adds a new option, --print-build-vars, > that > >> prints them out explicitly. > >> > >> > >> Diffs > >> ----- > >> > >> SConstruct cf1afc88070f > >> > >> Diff: http://reviews.m5sim.org/r/531/diff > >> > >> > >> Testing > >> ------- > >> > >> > >> Thanks, > >> > >> Gabe > >> > >> _______________________________________________ > >> m5-dev mailing list > >> m5-dev@m5sim.org > >> http://m5sim.org/mailman/listinfo/m5-dev > > _______________________________________________ > > m5-dev mailing list > > m5-dev@m5sim.org > > http://m5sim.org/mailman/listinfo/m5-dev > > > > ------------------------------ > > Message: 3 > Date: Fri, 04 Mar 2011 00:52:42 -0000 > From: "Brad Beckmann" <brad.beckm...@amd.com> > To: "Nilay Vaish" <ni...@cs.wisc.edu>, "Default" <m5-dev@m5sim.org>, > "Brad Beckmann" <brad.beckm...@amd.com> > Subject: Re: [m5-dev] Review Request: Ruby: Add stall and wait to MESI > CMP directory > Message-ID: <20110304005242.9667.20...@daystrom.m5sim.org> > Content-Type: text/plain; charset="utf-8" > > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.m5sim.org/r/330/#review928 > ----------------------------------------------------------- > > > Do you have to always call wakeUpAllDependents? Initially it atleast was > my hope that the per cache block wakeUpDependents would be sufficient. > However, I could see that in certain situations where requets are stalled > because a tbe entry is unavailable that the per address wakeUpDependents > could lead to starvation. Do you think we should just elimiate > wakeUpDependents and just use wakeUpAllDependents? > > - Brad > > > On 2011-03-03 09:20:38, Nilay Vaish wrote: > > > > ----------------------------------------------------------- > > This is an automatically generated e-mail. To reply, visit: > > http://reviews.m5sim.org/r/330/ > > ----------------------------------------------------------- > > > > (Updated 2011-03-03 09:20:38) > > > > > > Review request for Default. > > > > > > Summary > > ------- > > > > This patch adds the stall and wait on the mandatory queue of L1 cache > > controller of the MESI CMP directory protocol. It is intended to be > > more of a discussion (so as to improve my understanding). > > > > > > Diffs > > ----- > > > > src/cpu/testers/rubytest/RubyTester.py 92229cb0cee9 > > src/mem/protocol/MESI_CMP_directory-L1cache.sm 92229cb0cee9 > > > > Diff: http://reviews.m5sim.org/r/330/diff > > > > > > Testing > > ------- > > > > The changes have been tested for 16 processors for 40 different random > > seeds with number of loads varying from a 1,000,000 - 4,000,000. The only > > concern is that I had to change the dead lock threshold in RubyTester.py > > which is surprising. > > > > > > Thanks, > > > > Nilay > > > > > > > > ------------------------------ > > Message: 4 > Date: Fri, 04 Mar 2011 01:14:42 -0000 > From: "Nilay Vaish" <ni...@cs.wisc.edu> > To: "Nilay Vaish" <ni...@cs.wisc.edu>, "Default" <m5-dev@m5sim.org>, > "Brad Beckmann" <brad.beckm...@amd.com> > Subject: Re: [m5-dev] Review Request: Ruby: Add stall and wait to MESI > CMP directory > Message-ID: <20110304011442.10939.56...@daystrom.m5sim.org> > Content-Type: text/plain; charset="utf-8" > > > > > On 2011-03-03 16:52:42, Brad Beckmann wrote: > > > Do you have to always call wakeUpAllDependents? Initially it atleast > was my hope that the per cache block wakeUpDependents would be sufficient. > However, I could see that in certain situations where requets are stalled > because a tbe entry is unavailable that the per address wakeUpDependents > could lead to starvation. Do you think we should just elimiate > wakeUpDependents and just use wakeUpAllDependents? > > Brad, I also thought that stalling on cache block basis should be > sufficient. In > fact my initial code used wakeUpDependents() only. But that did not work > out, and > I was not able to figure out why that might be the case. And then I thought > that > stalling requests on a particular address might not be correct. Let me pose > this > question to you, is stalling on an address same as stalling on a cache > block? If it > is, then certainly I do not see the need for wakeUpAllDependents(), at > least not in > the MESI L1 cache controller. But in case the two are not same, then I > think we would > need to wake up all requests whenever there is a transition from a > transient to a > stable state. > > > - Nilay > > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.m5sim.org/r/330/#review928 > ----------------------------------------------------------- > > > On 2011-03-03 09:20:38, Nilay Vaish wrote: > > > > ----------------------------------------------------------- > > This is an automatically generated e-mail. To reply, visit: > > http://reviews.m5sim.org/r/330/ > > ----------------------------------------------------------- > > > > (Updated 2011-03-03 09:20:38) > > > > > > Review request for Default. > > > > > > Summary > > ------- > > > > This patch adds the stall and wait on the mandatory queue of L1 cache > > controller of the MESI CMP directory protocol. It is intended to be > > more of a discussion (so as to improve my understanding). > > > > > > Diffs > > ----- > > > > src/cpu/testers/rubytest/RubyTester.py 92229cb0cee9 > > src/mem/protocol/MESI_CMP_directory-L1cache.sm 92229cb0cee9 > > > > Diff: http://reviews.m5sim.org/r/330/diff > > > > > > Testing > > ------- > > > > The changes have been tested for 16 processors for 40 different random > > seeds with number of loads varying from a 1,000,000 - 4,000,000. The only > > concern is that I had to change the dead lock threshold in RubyTester.py > > which is surprising. > > > > > > Thanks, > > > > Nilay > > > > > > > > ------------------------------ > > Message: 5 > Date: Fri, 04 Mar 2011 01:18:01 -0000 > From: "Gabe Black" <gbl...@eecs.umich.edu> > To: "Steve Reinhardt" <ste...@gmail.com>, "Ali Saidi" > <sa...@umich.edu>, "Gabe Black" <gbl...@eecs.umich.edu>, > "Nathan > Binkert" <n...@binkert.org> > Cc: Default <m5-dev@m5sim.org> > Subject: [m5-dev] Review Request: Mips: MIPS_FS doesn't build > currently, so delete it to avoid confusion. > Message-ID: <20110304011801.11131.42...@daystrom.m5sim.org> > Content-Type: text/plain; charset="utf-8" > > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.m5sim.org/r/532/ > ----------------------------------------------------------- > > Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and > Nathan Binkert. > > > Summary > ------- > > Mips: MIPS_FS doesn't build currently, so delete it to avoid confusion. > > MIPS_FS doesn't build and presumably doesn't work right now. Users might > see > the MIP_FS file in build_opts and expect it to work. To avoid confusion, > this > change deletes that file. > > > Diffs > ----- > > build_opts/MIPS_FS 92229cb0cee9 > > Diff: http://reviews.m5sim.org/r/532/diff > > > Testing > ------- > > > Thanks, > > Gabe > > > > ------------------------------ > > Message: 6 > Date: Fri, 04 Mar 2011 01:54:51 -0000 > From: "Korey Sewell" <ksew...@umich.edu> > To: "Steve Reinhardt" <ste...@gmail.com>, "Ali Saidi" > <sa...@umich.edu>, "Gabe Black" <gbl...@eecs.umich.edu>, > "Nathan > Binkert" <n...@binkert.org> > Cc: Default <m5-dev@m5sim.org> > Subject: Re: [m5-dev] Review Request: Mips: MIPS_FS doesn't build > currently, so delete it to avoid confusion. > Message-ID: <20110304015451.11378.35...@daystrom.m5sim.org> > Content-Type: text/plain; charset="utf-8" > > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.m5sim.org/r/532/#review930 > ----------------------------------------------------------- > > Ship it! > > > - Korey > > > On 2011-03-03 17:18:01, Gabe Black wrote: > > > > ----------------------------------------------------------- > > This is an automatically generated e-mail. To reply, visit: > > http://reviews.m5sim.org/r/532/ > > ----------------------------------------------------------- > > > > (Updated 2011-03-03 17:18:01) > > > > > > Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and > Nathan Binkert. > > > > > > Summary > > ------- > > > > Mips: MIPS_FS doesn't build currently, so delete it to avoid confusion. > > > > MIPS_FS doesn't build and presumably doesn't work right now. Users might > see > > the MIP_FS file in build_opts and expect it to work. To avoid confusion, > this > > change deletes that file. > > > > > > Diffs > > ----- > > > > build_opts/MIPS_FS 92229cb0cee9 > > > > Diff: http://reviews.m5sim.org/r/532/diff > > > > > > Testing > > ------- > > > > > > Thanks, > > > > Gabe > > > > > > > > ------------------------------ > > Message: 7 > Date: Thu, 3 Mar 2011 19:05:12 -0700 > From: Yi Xiang <y...@colostate.edu> > To: m5-dev@m5sim.org > Subject: [m5-dev] A small bug on thread pid and start time. > Message-ID: > <aanlktiknvy1ndz9ekftd5dscqz5zrfawg-dqm_xpb...@mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > I found a bug while trying to generate trace file for thread execution. At > first, --trace-thread returned wrong value for thread tid and start time. > For example, tids for all the threads are 3211264. > > Actually, this bug can be fixed by changing from "Addr offset" to "ini32_t > offset" in line106 and line 119 of threadinfo.hh. > > After this change, I got the right thread pid. > > All the best. > > Yi Xiang > > > ------------------------------ > > Message: 8 > Date: Thu, 3 Mar 2011 21:23:56 -0500 > From: Korey Sewell <ksew...@umich.edu> > To: M5 Developer List <m5-dev@m5sim.org> > Subject: Re: [m5-dev] A small bug on thread pid and start time. > Message-ID: > <aanlktim-j3wmpvkaehcybund-qrjq+q6nr6ggrsqj...@mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Many more details are needed for us to incorporate this bug fix. > > What is the command line you ran that caused the error? > > What is the output that shows the error? > > What files do you change to fix the error? > > On Thu, Mar 3, 2011 at 9:05 PM, Yi Xiang <y...@colostate.edu> wrote: > > > I found a bug while trying to generate trace file for thread execution. > At > > first, --trace-thread returned wrong value for thread tid and start time. > > For example, tids for all the threads are 3211264. > > > > Actually, this bug can be fixed by changing from "Addr offset" to > "ini32_t > > offset" in line106 and line 119 of threadinfo.hh. > > > > After this change, I got the right thread pid. > > > > All the best. > > > > Yi Xiang > > _______________________________________________ > > m5-dev mailing list > > m5-dev@m5sim.org > > http://m5sim.org/mailman/listinfo/m5-dev > > > > > > -- > - Korey > > > ------------------------------ > > Message: 9 > Date: Thu, 03 Mar 2011 22:20:46 -0500 > From: Gabriel Michael Black <gbl...@eecs.umich.edu> > To: m5-dev@m5sim.org > Subject: Re: [m5-dev] A small bug on thread pid and start time. > Message-ID: <20110303222046.81453dag16liw...@mail.eecs.umich.edu> > Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; > format="flowed" > > They did mention the line that needed to be changed, so that's covered. > > But I think we'll still need that other information (how to reproduce > it, basically) so we can verify the fix ourselves. In any case, thanks > for letting us know! > > Gabe > > Quoting Korey Sewell <ksew...@umich.edu>: > > > Many more details are needed for us to incorporate this bug fix. > > > > What is the command line you ran that caused the error? > > > > What is the output that shows the error? > > > > What files do you change to fix the error? > > > > On Thu, Mar 3, 2011 at 9:05 PM, Yi Xiang <y...@colostate.edu> wrote: > > > >> I found a bug while trying to generate trace file for thread execution. > At > >> first, --trace-thread returned wrong value for thread tid and start > time. > >> For example, tids for all the threads are 3211264. > >> > >> Actually, this bug can be fixed by changing from "Addr offset" to > "ini32_t > >> offset" in line106 and line 119 of threadinfo.hh. > >> > >> After this change, I got the right thread pid. > >> > >> All the best. > >> > >> Yi Xiang > >> _______________________________________________ > >> m5-dev mailing list > >> m5-dev@m5sim.org > >> http://m5sim.org/mailman/listinfo/m5-dev > >> > > > > > > > > -- > > - Korey > > _______________________________________________ > > m5-dev mailing list > > m5-dev@m5sim.org > > http://m5sim.org/mailman/listinfo/m5-dev > > > > > > > ------------------------------ > > _______________________________________________ > m5-dev mailing list > m5-dev@m5sim.org > http://m5sim.org/mailman/listinfo/m5-dev > > > End of m5-dev Digest, Vol 47, Issue 10 > ************************************** > _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
