[gem5-dev] Re: A few quick thoughts

[Gutierrez, Anthony via gem5-dev]

[AMD Public Use]

Hey, Jason perhaps you mentioned this somewhere but what is the reason for such 
a strong aversion to the template approach? It seems to solve the issue nicely 
with what seems to be a minor change in syntax. gem5 is C++, so we should allow 
users to write C++.

Tony

From: Jason Lowe-Power via gem5-dev 
Sent: Friday, September 18, 2020 8:05 AM
To: Gabe Black 
Cc: gem5 Developer List ; Jason Lowe-Power 

Subject: [gem5-dev] Re: A few quick thoughts

[CAUTION: External Email]
There is another option to keep the function-like syntax, but get the constexpr 
via templates: A preprocessor macro:

#define bits(val, first, last) bits(val)

The major downside is that we can't overload preprocessor macros. We'd have to 
have two name bits_const() and bits(), which I also don't like.

Personally, I strongly don't want to lose the function-like syntax for the bits 
function. I won't *block* the change, but I'll push back against the template 
syntax.

Cheers,
Jason

On Fri, Sep 18, 2020 at 5:02 AM Gabe Black 
mailto:gabebl...@google.com>> wrote:
I spent some more time digging into 2, and while I didn't find anything that 
directly stated that you aren't allowed to do that, without explicit support I 
think it flies in the face of how C++ templates, types, etc. work to the point 
where if you *did* find a way to do it, it would almost certainly be a bug or 
an oversight in the standard somewhere. So unless they do adopt one of those 
standards I saw proposed and we wait a good number of years for it to be 
implemented in all the compilers we support (one said it targeted C++23) I 
think templates, while slightly gross, are really the only way to make it work.

Gabe

On Thu, Sep 17, 2020 at 2:53 PM Jason Lowe-Power 
mailto:ja...@lowepower.com>> wrote:


On Thu, Sep 17, 2020 at 2:48 PM Gabe Black via gem5-dev 
mailto:gem5-dev@gem5.org>> wrote:
1. Sounds good, I'll hopefully have some time to put together a CL in no too 
long (weekend?).

2. I 5ries to figure out a way to do it without the template that wasn't really 
gross a somewhat fragile and wasn't able to, but that would definitely be 
preferable. I'll keep thinking about it, but the internet didn't seem to have 
any ideas either. Unfortunately using constexpr won't work like that Jason, 
although I wish it did and found a couple unadopted (as far as I know) 
standards proposals to that effect.

Yeah, that's what I found, too :).


3. Sounds good. Likely this weekend?

Gabe

On Thu, Sep 17, 2020, 1:15 PM Bobby Bruce via gem5-dev 
mailto:gem5-dev@gem5.org>> wrote:
1) Seems fine to me.

2) I remember looking into this and I agree with Jason, it involves template 
magic which I'm not a huge fan of. I feel like in order to add these compile 
time asserts we'd be sacrificing some readability/ease-of-usability of 
bitfields.hh. This may just be a "me thing", but something about templates 
confuse me whenever I need to deal with them.

3) In truth, our minimum supported Clang version is 3.9 in practise (We even 
state on our website's building documentation that we support Clang 3.9 to 9: 
http://www.gem5.org/documentation/general_docs/building).
 I didn't realize we still have "3.1" hardcoded in the SConscript and would be 
happy for this to be bumped up to 3.9. Our compiler tests do not test with 
versions of clang before 3.9, so, at present, we aren't doing much to help 
those using versions older than 3.9. I'd love to bump up to c++14 also. While 
I'm sure there are plenty of good reasons, I personally would like to use 
C++14's deprecation attribute for if/when we start deprecating gem5 C++ APIs: 
https://en.cppreference.com/w/cpp/language/attributes/deprecated

We already do use the deprecated attribute (see 
https://gem5.googlesource.com/public/gem5/+/refs/heads/develop/src/base/compiler.hh#55).

We should be able to get rid of this: 
https://gem5.googlesource.com/public/gem5/+/refs/heads/develop/src/base/compiler.hh#9

[gem5-dev] Lots of GPU changes will be pushed soon.

[Gutierrez, Anthony via gem5-dev]

[AMD Official Use Only - Internal Distribution Only]

Hi All,

Jason asked me to send a heads up since I plan to push a bunch of GPU changes, 
mostly the ones seen on the first page of the log for my staging branch: 
https://gem5.googlesource.com/amd/gem5/+log/refs/heads/agutierr/master-gcn3-staging,
 fairly quickly as we have a stretch goal to get much of the GPU code in for 
the gem5 20 release. The code I'll be pushing will not be touching files 
outside of gpu-compute or arch/gcn3, if it does I'll wait for proper review. 
For the GPU changes they have been thoroughly reviewed by experts within AMD 
and pass a large suite of GPU application tests, so I don't imagine reviews are 
necessary for anything other than style, which should also have been vetted in 
our internal review process.

That said, I'll leave the code up for a day or two so folks can go through it, 
but I'll likely be pushing it with/without reviews pretty rapidly.

Thanks,
Tony
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

Re: [gem5-dev] gerrit pickiness interacting with kokoro

[Gutierrez, Anthony]

I am fine with this.

Tony

-Original Message-
From: gem5-dev  On Behalf Of Gabe Black
Sent: Monday, April 29, 2019 7:39 PM
To: gem5 Developer List 
Cc: Rahul Thakur 
Subject: Re: [gem5-dev] gerrit pickiness interacting with kokoro

[CAUTION: External Email]

Hello again. I asked the gurus, and they say we probably want to set content 
merging to true. Any objections? I'd like to flip that switch before I go on my 
trip, so by the end of the week.

Gabe

On Sat, Apr 27, 2019 at 5:09 PM Gabe Black  wrote:

> Hi folks. It's historically been an issue with gerrit as we have it 
> set up for use in gem5 that it seems to be pretty picky about when a 
> change can be submitted, and I've had to fairly often (but not always) 
> perform a trivial rebase through the gerrit UI so that it's happy and 
> will let me submit a CL. In the past this has been annoying, but not a 
> big deal since it just takes a few clicks to placate gerrit.
>
> Now that we have kokoro running and verifying CLs (which is a very 
> good thing), rebases have the unfortunate side effect of clearing the 
> verified bit which necessitates running the CI again on essentially 
> the same CL, including a several hour wait. So far this has been a 
> bigger annoyance than before with the added latency getting a CL 
> submitted, but since there haven't (yet) been any series with a lot of 
> those delays stack on top of each other it hasn't been a huge problem.
>
> What I'd like to know is what people think about making gerrit less 
> picky (not sure how that translates to settings TBH) so that these 
> trivial rebases aren't as necessary. Looking at the settings, I see 
> that the "Submit type" is "Rebase Always" and the "Allow content 
> merges" setting is false. There are other settings, but these seem like the 
> most relevant ones.
>
> This page takes a bit about the philosophy behind the submit type setting:
>
>
> https://gerrit-review.googlesource.com/Documentation/intro-project-own
> er.html
>
> With a more complete description of all the submit types over here:
>
>
> https://gerrit-review.googlesource.com/Documentation/config-project-co
> nfig.html#submit-type
>
> If people agree that this is something we should try to change, we can 
> probably ask the gerrit gurus here at Google what settings we can 
> adjust to get the desired effect.
>
> Gabe
>
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] [gem5-users] GPU

[Gutierrez, Anthony]

There are some instructions about how to build the software stack for the GPU 
model here: http://gem5.org/GPU_Models

You’ll need to build the ROCr (runtime) ROCt (thunk) and HCC (clang/llvm 
compiler), and probably HIP too as most available codes are in HIP. For 
example, the Rodinia benchmarks have been hipified here: 
https://github.com/ROCm-Developer-Tools/HIP-Examples/tree/master/rodinia_3.0/hip

The recommended branches are listed on the site, however most users have not 
been able to get them to run in the simulator.

These are shas for each repo known to work in gem5:

HCC: 7d030799dca53d39f141d60c73950966501b3ffb
ROCr: f92eba2a8b0d5e9a8fa28a127bd1eb59f03d3eb0
ROCt: d13b4e2e2413cb20e8cc2bcdd419f06f499f306e
HIP: 0e3d824e8d8f1ec3e31b26fa1f2e46fd3e6d4241


From: gem5-users  On Behalf Of Krishna Subramanian
Sent: Thursday, February 7, 2019 12:26 PM
To: gem5 Developer List ; gem5-us...@gem5.org
Subject: [gem5-users] GPU

Hi

I was able to successfully run the GPU Hello included in the gem5 distribution 
using the HSAIL build. However i was wondering how to write my own 
openCL/different language program and compile it all the way down to an 
executable binary on the HSAIL ( or the equivalent in GCN3). Is there any 
tutorial/methodology you can point me to if available.

Thank you for your time
Best,
Krishna
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Running AMD GPU

[Gutierrez, Anthony]

That benchmark was for HSAIL ISA, and therefore doesn't run with the GCN3 ISA.

I removed that test from our repo 
(https://gem5.googlesource.com/amd/gem5/+/b021dd69fef50a0ccd8883d65225af9ff8bb6682).
 Currently we provide no benchmarks that run out of the box on the APU model.

Tony

-Original Message-
From: gem5-dev  On Behalf Of Krishna Subramanian
Sent: Friday, January 25, 2019 1:41 PM
To: gem5-dev@gem5.org
Subject: [gem5-dev] Running AMD GPU

Hi

I am trying to run the GCN3 in gem5 as mentioned in the gem5 webpage. I have 
built it successfully. However when i try to run a program *GPU-Hello* using 
the command

./build/GCN3_X86/gem5.opt configs/example/apu_se.py -c 
tests/test-progs/gpu-hello/bin/x86/lnux/gpu-hello

It starts the execution and then shows an error *Failed to open /dev/hsa. * No 
traceback , nothing.

Your help is appreciated.
Best
Krishna Subramanian
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Problem with dyn insts/refcnt pointers in O3 LSQ.

[Gutierrez, Anthony]

Got around to debugging this today. Turns out it had nothing to do with the 
refcnt changes. It was a subtle but introduced in the LSQUnit here:

https://gem5.googlesource.com/public/gem5/+/9af1214ffe48178c0dadfb874fd62bd0ff2e0f31

Fix is here:

https://gem5-review.googlesource.com/c/public/gem5/+/15015

I am guessing the reason this didn't get caught by the upstream tester is that 
it only uses the default LQ/SQ sizes, which are both 32, and thus this isn't an 
issue? Although, I didn't verify that the tester doesn't ever use differing 
LQ/SQ sizes.

Tony

-Original Message-
From: gem5-dev  On Behalf Of Giacomo Travaglini
Sent: Friday, December 7, 2018 5:48 AM
To: gem5 Developer List 
Subject: Re: [gem5-dev] Problem with dyn insts/refcnt pointers in O3 LSQ.

Hi Tony,


We use gcc 5.4.0 like you do, and we didn't find any issues whatsoever* (which 
is,

we don't see any segafult happening on O3 regressions)


You can verify this by yourself by running upstream regressions


There is probably something going wrong in the integration

of the patch into your internal fork of gem5. I cannot really help you a lot; 
judging by

your bug report it seems to me that there is an unwanted MOVE

(since you have nullptr and the patch is adding move semantics)


Regards


Giacomo



*There is an arm only failure caused by another patch, we are currently looking 
into

that.




From: gem5-dev  on behalf of Gutierrez, Anthony 

Sent: 06 December 2018 18:11:12
To: gem5 Developer List
Subject: Re: [gem5-dev] Problem with dyn insts/refcnt pointers in O3 LSQ.

Yes, sorry, I should have clarified which Giacomo.

We are running various GPU benchmarks that link against the ROCm runtime in SE 
mode.

We have internal changes, as this is a merge of upstream master into our 
internal amd-master branch, but the simulation fails so quickly that we're only 
executing a handful of memory insts. We don't really have any changes to the 
CPU model in our internal branch.

Do you test with GCC or only clang?

-Original Message-
From: gem5-dev  On Behalf Of Giacomo Travaglini
Sent: Thursday, December 6, 2018 9:04 AM
To: gem5 Developer List 
Subject: Re: [gem5-dev] Problem with dyn insts/refcnt pointers in O3 LSQ.

Hi Tony,


I guess you are referring to Giacomo Gabrielli (and not me); I will address 
your comments in any case.

Can I ask you


1) Which kind of tests are you talking about? We have run the regressions 
before posting the change and we didn't find any

issue. I will rerun them again just to double check


2) Are you running with upstream master or with your internal branch?


Thanks


Giacomo

____
From: gem5-dev  on behalf of Gutierrez, Anthony 

Sent: 05 December 2018 22:54:53
To: gem5 Developer List
Subject: Re: [gem5-dev] Problem with dyn insts/refcnt pointers in O3 LSQ.

I forgot to mention, I am on RHEL 7.3 using gcc 5.4.0

From: Gutierrez, Anthony
Sent: Wednesday, December 5, 2018 2:52 PM
To: gem5-dev@gem5.org
Subject: Problem with dyn insts/refcnt pointers in O3 LSQ.

Hi All,

I am getting a segfault almost immediately after simulation starts, I think due 
to this change: https://gem5-review.googlesource.com/c/public/gem5/+/13105/5, 
as I'm attempting to merge master into our internal master branch.

What I see happening is that LSQUnit::executeStore() calls 
LSQUnit::checkViolations() and at some point DynInstPtr ld_inst = 
loadQueue[load_idx]; returns a DynInstPtr whose data is null.

I haven't looked at the recent changes to the DynInst and RefCountingPtr 
closely, but I'm guessing somehow the reference count for the obj is not 
tracked properly at some point and the object is deleted.

Giacomo, do you have any idea what could be causing this? In the meantime, I'll 
do some debugging to try to understand the issue better.

Thanks,
Tony
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
_

Re: [gem5-dev] Problem with dyn insts/refcnt pointers in O3 LSQ.

[Gutierrez, Anthony]

Yes, sorry, I should have clarified which Giacomo.

We are running various GPU benchmarks that link against the ROCm runtime in SE 
mode.

We have internal changes, as this is a merge of upstream master into our 
internal amd-master branch, but the simulation fails so quickly that we're only 
executing a handful of memory insts. We don't really have any changes to the 
CPU model in our internal branch.

Do you test with GCC or only clang?

-Original Message-
From: gem5-dev  On Behalf Of Giacomo Travaglini
Sent: Thursday, December 6, 2018 9:04 AM
To: gem5 Developer List 
Subject: Re: [gem5-dev] Problem with dyn insts/refcnt pointers in O3 LSQ.

Hi Tony,


I guess you are referring to Giacomo Gabrielli (and not me); I will address 
your comments in any case.

Can I ask you


1) Which kind of tests are you talking about? We have run the regressions 
before posting the change and we didn't find any

issue. I will rerun them again just to double check


2) Are you running with upstream master or with your internal branch?


Thanks


Giacomo


From: gem5-dev  on behalf of Gutierrez, Anthony 

Sent: 05 December 2018 22:54:53
To: gem5 Developer List
Subject: Re: [gem5-dev] Problem with dyn insts/refcnt pointers in O3 LSQ.

I forgot to mention, I am on RHEL 7.3 using gcc 5.4.0

From: Gutierrez, Anthony
Sent: Wednesday, December 5, 2018 2:52 PM
To: gem5-dev@gem5.org
Subject: Problem with dyn insts/refcnt pointers in O3 LSQ.

Hi All,

I am getting a segfault almost immediately after simulation starts, I think due 
to this change: https://gem5-review.googlesource.com/c/public/gem5/+/13105/5, 
as I'm attempting to merge master into our internal master branch.

What I see happening is that LSQUnit::executeStore() calls 
LSQUnit::checkViolations() and at some point DynInstPtr ld_inst = 
loadQueue[load_idx]; returns a DynInstPtr whose data is null.

I haven't looked at the recent changes to the DynInst and RefCountingPtr 
closely, but I'm guessing somehow the reference count for the obj is not 
tracked properly at some point and the object is deleted.

Giacomo, do you have any idea what could be causing this? In the meantime, I'll 
do some debugging to try to understand the issue better.

Thanks,
Tony
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Problem with dyn insts/refcnt pointers in O3 LSQ.

[Gutierrez, Anthony]

I forgot to mention, I am on RHEL 7.3 using gcc 5.4.0

From: Gutierrez, Anthony
Sent: Wednesday, December 5, 2018 2:52 PM
To: gem5-dev@gem5.org
Subject: Problem with dyn insts/refcnt pointers in O3 LSQ.

Hi All,

I am getting a segfault almost immediately after simulation starts, I think due 
to this change: https://gem5-review.googlesource.com/c/public/gem5/+/13105/5, 
as I'm attempting to merge master into our internal master branch.

What I see happening is that LSQUnit::executeStore() calls 
LSQUnit::checkViolations() and at some point DynInstPtr ld_inst = 
loadQueue[load_idx]; returns a DynInstPtr whose data is null.

I haven't looked at the recent changes to the DynInst and RefCountingPtr 
closely, but I'm guessing somehow the reference count for the obj is not 
tracked properly at some point and the object is deleted.

Giacomo, do you have any idea what could be causing this? In the meantime, I'll 
do some debugging to try to understand the issue better.

Thanks,
Tony
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] Problem with dyn insts/refcnt pointers in O3 LSQ.

[Gutierrez, Anthony]

Hi All,

I am getting a segfault almost immediately after simulation starts, I think due 
to this change: https://gem5-review.googlesource.com/c/public/gem5/+/13105/5, 
as I'm attempting to merge master into our internal master branch.

What I see happening is that LSQUnit::executeStore() calls 
LSQUnit::checkViolations() and at some point DynInstPtr ld_inst = 
loadQueue[load_idx]; returns a DynInstPtr whose data is null.

I haven't looked at the recent changes to the DynInst and RefCountingPtr 
closely, but I'm guessing somehow the reference count for the obj is not 
tracked properly at some point and the object is deleted.

Giacomo, do you have any idea what could be causing this? In the meantime, I'll 
do some debugging to try to understand the issue better.

Thanks,
Tony
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Assertion during simulation with GCN3

[Gutierrez, Anthony]

The address that is failing seems suspect. You may want to get a GPUALL trace 
to see which GPU instruction is sending the faulty address, as well as which 
instructions generate the offending memory instruction's address operands.

Tony

-Original Message-
From: gem5-dev  On Behalf Of Sungkeun Kim
Sent: Tuesday, October 09, 2018 9:17 PM
To: gem5-dev@gem5.org
Subject: [gem5-dev] Assertion during simulation with GCN3

Hi Tony and Tuan,

I am Sungkeun Kim and I am interested in GCN3. So I am trying to run a 
lulesh-amp application(
https://github.com/AMDComputeLibraries/ComputeApps/tree/master/lulesh-amp)
using gem5 GCN3_X83. However, whenever I run the simulation, it's aborted with 
following assertion.

3076817gem5.opt: build/GCN3_X86/gpu-compute/gpu_tlb.cc:1201: void 
X86ISA::GpuTLB::handleTranslationReturn(Addr, X86ISA::GpuTLB::tlbOutcome,
PacketPtr): Assertion `new_entry' failed.
I am not sure whether it is a bug in GCN3 implementation or my mistake in 
configuration or environment settings.
Could give me any hint or guide for this? Followings are logs and my settings. 
I can share full logs if you want.

### BACKTRACE ##
Program aborted at tick 307682795000
--- BEGIN LIBC BACKTRACE ---
./build/GCN3_X86/gem5.opt(_Z15print_backtracev+0x28)[0xca7ca8]
./build/GCN3_X86/gem5.opt(_Z12abortHandleri+0x46)[0xcba826]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x11390)[0x7fa112f69390]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x38)[0x7fa111971428]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x16a)[0x7fa11197302a]
/lib/x86_64-linux-gnu/libc.so.6(+0x2dbd7)[0x7fa111969bd7]
/lib/x86_64-linux-gnu/libc.so.6(+0x2dc82)[0x7fa111969c82]
./build/GCN3_X86/gem5.opt(_ZN6X86ISA6GpuTLB23handleTranslationReturnEmNS0_10tlbOutcomeEP6Packet+0x487)[0x11bb937]
./build/GCN3_X86/gem5.opt(_ZN6X86ISA6GpuTLB17translationReturnEmNS0_10tlbOutcomeEP6Packet+0x38f)[0x11bbd0f]
./build/GCN3_X86/gem5.opt(_ZN10EventQueue10serviceOneEv+0x11d)[0xcae4ed]
./build/GCN3_X86/gem5.opt(_Z9doSimLoopP10EventQueue+0x50)[0xcc6ee0]
./build/GCN3_X86/gem5.opt(_Z8simulatem+0xd1b)[0xcc7fcb]
./build/GCN3_X86/gem5.opt[0x1b0bd0a]
./build/GCN3_X86/gem5.opt[0xd10415]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x7852)[0x7fa113226772]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x85c)[0x7fa11335d05c]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x6ffd)[0x7fa113225f1d]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x85c)[0x7fa11335d05c]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCode+0x19)[0x7fa11321eda9]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x613b)[0x7fa11322505b]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x85c)[0x7fa11335d05c]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x6ffd)[0x7fa113225f1d]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x85c)[0x7fa11335d05c]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCode+0x19)[0x7fa11321eda9]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyRun_StringFlags+0x76)[0x7fa1132991f6]
./build/GCN3_X86/gem5.opt(_Z6m5MainiPPc+0x8f)[0xcb921f]
./build/GCN3_X86/gem5.opt(main+0x33)[0x8d3243]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7fa11195c830]
./build/GCN3_X86/gem5.opt(_start+0x29)[0x8f8239]
--- END LIBC BACKTRACE ---


### LAST FEW LOGS (GPUTLB enable) 
##

307681898000: system.l2_tlb: This is a TLB miss
307681898000: system.l3_coalescer-port0: receiving pkt w/ req_cnt 3
307681898000: system.l3_coalescer-port0: coalescerFIFO[307681826000] now has 2 
coalesced reqs after push
307681898000: system.l2_tlb: Sent translation request to lower level TLB for 
addr 0x1700014000
307681899000: system.l3_coalescer: triggered TLBCoalescer processProbeTLBEvent
307681899000: system.l3_coalescer: coalescedReq_cnt is 2 for tick_index
307681826000
307681899000: system.l3_tlb: Translation req. for virt. page addr
0x1700013000
307681899000: system.l3_tlb: TLB Lookup for vaddr 0x1700013b7a.
307681899000: system.l3_tlb: In protected mode.
307681899000: system.l3_tlb: Paging enabled.
307681899000: system.l3_tlb: schedule translationReturnEvent @ curTick
307682049000
307681899000: system.l3_coalescer: system.l3_coalescer sending pkt w/ req_cnt 11
307681899000: system.l3_coalescer: Successfully sent TLB request for page
0x1700013000307681899000: system.l3_tlb: Translation req. for virt. page addr 
0x1700014000
307681899000: system.l3_tlb: TLB Lookup for vaddr 0x17000142ee.
307681899000: system.l3_tlb: In protected mode.
307681899000: system.l3_tlb: Paging enabled.
307681899000: system.l3_tlb: schedule translationReturnEvent @ curTick
307682049000
307681899000: system.l3_coalescer: system.l3_coalescer sending pkt w/ req_cnt 3
307681899000: system.l3_coalescer: Successfully sent TLB request for page
0x1700014000307682045000: system.l3_tlb: Triggered TLBEven

Re: [gem5-dev] Gem5 Compile issue : Commit :\te02ec0c24d56bce4a0d8636a340e15cd223d1930

[Gutierrez, Anthony]

That print was always that way if I remember correctly. It may be a problem 
with the application itself.

From: gem5-dev  on behalf of Sampad Mohapatra 

Sent: Friday, August 17, 2018 10:31:44 AM
To: gem5-dev@gem5.org
Subject: Re: [gem5-dev] Gem5 Compile issue : Commit : 
e02ec0c24d56bce4a0d8636a340e15cd223d1930

Hi all,

Thank you for your help.
As Brandon pointed out that the test prog prints wrong values, can anyone
point out the commit that contains a relatively stable GPU model (HSAIL).

Regards
Sampad

On Thu, Aug 16, 2018 at 9:11 PM Potter, Brandon 
wrote:

> Hello all,
>
> The hsail-x86 target will compile with the following changes. I tried
> running the gpu-hello program with the build and it prints "lelellelelelel"
> instead of "hello*". FWIW, the code compiles now which is an improvement.
>
>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgem5-review.googlesource.com%2Fc%2Fpublic%2Fgem5%2F%2B%2F12107&data=02%7C01%7Csum94%40psu.edu%7C5c8dcf0d07004e2f327008d603de6495%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C636700651042545326&sdata=LaslfnQGn5DmoYop8Knf3zcul4OUs9C8fVpq9VH5GFU%3D&reserved=0
>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgem5-review.googlesource.com%2Fc%2Fpublic%2Fgem5%2F%2B%2F12108&data=02%7C01%7Csum94%40psu.edu%7C5c8dcf0d07004e2f327008d603de6495%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C636700651042545326&sdata=lw5cTUcyavi80bxe8EBh62u2kwY3FdbPnzmKLBXa8xY%3D&reserved=0
>
> We are currently in the process of making the GCN3 implementation public
> which will supplant the hsail-x86 target entirely. The newer code should
> appear in the gem5 source within the next few weeks.
>
> Regards,
> Brandon
>
> P.S. Buy EPYC instead of Xeon.
>
> -Original Message-
> From: Gutierrez, Anthony
> Sent: Thursday, August 16, 2018 1:24 PM
> To: gem5 Developer List 
> Cc: Potter, Brandon 
> Subject: RE: [gem5-dev] Gem5 Compile issue : Commit :
> e02ec0c24d56bce4a0d8636a340e15cd223d1930
>
> Did the recent changes break that? Last time I pushed to the public and
> ran the tester gpu-hello worked. I'm guessing whichever change broken this
> was not ever tested using the regression tester?
>
> HSAIL is deprecated meaning we no longer support it, but that said it
> should still work. We plan on trying to push our GCN3 model to the master
> branch, which is what removes HSAIL and we'd prefer to remove it from
> master that way, but as you know there are issues with that currently. We
> have some problematic changes to SE mode that need to be fixed up, as they
> are not likely to pass public review, although I believe they are
> functionally correct.
>
> Brandon may have a better idea of what needs to be done.
>
> -Original Message-
> From: gem5-dev  On Behalf Of Jason Lowe-Power
> Sent: Thursday, August 16, 2018 10:05 AM
> To: gem5 Developer List 
> Subject: Re: [gem5-dev] Gem5 Compile issue : Commit :
> e02ec0c24d56bce4a0d8636a340e15cd223d1930
>
> Hey Tony,
>
> If HSAIL is deprecated, should we remove it from the public repo?
>
> Also, from the nightly regressions the GPU test is broken:
>
> scons: *** [build/HSAIL_X86/gpu-compute/hsail_code.do] Error 1
> > scons: *** [build/HSAIL_X86/arch/hsail/gpu_decoder.do] Error 1
> > scons: *** [build/HSAIL_X86/gpu-compute/hsail_code.fo] Error 1
>
>
> Though, we've all been ignoring the emails from zizzer for a while now.
> Which reminds me, I would love some help porting tests over to the new
> infrastructure that will (hopefully) resolve these issues since it's easier
> to use.
>
> Cheers,
> Jason
>
> On Thu, Aug 16, 2018 at 9:55 AM Gutierrez, Anthony <
> anthony.gutier...@amd.com> wrote:
>
> > Sampad, are you trying to run our GPU model? If so, HSAIL is deprecated.
> > We released an updated version of our GPU simulator at
> > gem5.googlesource.com/amd/gem5 branch agutierr/master-gcn3-staging. I
> > recommend you starting with that.
> >
> > I don’t think anybody at AMD will have time to look into HSAIL bugs
> > for the time being, but doesn’t the current tester test at least 1 GPU
> > program (gpu hello)? How did the changes get by the tester?
> >
> > If you encounter issues with our GCN3 model, you can notify us through
> > the
> > gem5 mailing list.
> >
> > From: Jason Lowe-Power 
> > Sent: Thursday, August 16, 2018 9:46 AM
> > To: gem5 Developer List ; Gutierrez, Anthony <
> > anthony.gutier...@amd.com>
> > Subject: Re: [gem5-dev] Gem5 Compile issue : Commit :
> > e02ec0c24d56bce4a0d8636a340e15cd223d1930
> >
> > Hi Sampad,
> >
> > It looks 

Re: [gem5-dev] Gem5 Compile issue : Commit : e02ec0c24d56bce4a0d8636a340e15cd223d1930

[Gutierrez, Anthony]

Did the recent changes break that? Last time I pushed to the public and ran the 
tester gpu-hello worked. I'm guessing whichever change broken this was not ever 
tested using the regression tester?

HSAIL is deprecated meaning we no longer support it, but that said it should 
still work. We plan on trying to push our GCN3 model to the master branch, 
which is what removes HSAIL and we'd prefer to remove it from master that way, 
but as you know there are issues with that currently. We have some problematic 
changes to SE mode that need to be fixed up, as they are not likely to pass 
public review, although I believe they are functionally correct.

Brandon may have a better idea of what needs to be done.

-Original Message-
From: gem5-dev  On Behalf Of Jason Lowe-Power
Sent: Thursday, August 16, 2018 10:05 AM
To: gem5 Developer List 
Subject: Re: [gem5-dev] Gem5 Compile issue : Commit : 
e02ec0c24d56bce4a0d8636a340e15cd223d1930

Hey Tony,

If HSAIL is deprecated, should we remove it from the public repo?

Also, from the nightly regressions the GPU test is broken:

scons: *** [build/HSAIL_X86/gpu-compute/hsail_code.do] Error 1
> scons: *** [build/HSAIL_X86/arch/hsail/gpu_decoder.do] Error 1
> scons: *** [build/HSAIL_X86/gpu-compute/hsail_code.fo] Error 1


Though, we've all been ignoring the emails from zizzer for a while now.
Which reminds me, I would love some help porting tests over to the new 
infrastructure that will (hopefully) resolve these issues since it's easier to 
use.

Cheers,
Jason

On Thu, Aug 16, 2018 at 9:55 AM Gutierrez, Anthony < anthony.gutier...@amd.com> 
wrote:

> Sampad, are you trying to run our GPU model? If so, HSAIL is deprecated.
> We released an updated version of our GPU simulator at
> gem5.googlesource.com/amd/gem5 branch agutierr/master-gcn3-staging. I 
> recommend you starting with that.
>
> I don’t think anybody at AMD will have time to look into HSAIL bugs 
> for the time being, but doesn’t the current tester test at least 1 GPU 
> program (gpu hello)? How did the changes get by the tester?
>
> If you encounter issues with our GCN3 model, you can notify us through 
> the
> gem5 mailing list.
>
> From: Jason Lowe-Power 
> Sent: Thursday, August 16, 2018 9:46 AM
> To: gem5 Developer List ; Gutierrez, Anthony < 
> anthony.gutier...@amd.com>
> Subject: Re: [gem5-dev] Gem5 Compile issue : Commit :
> e02ec0c24d56bce4a0d8636a340e15cd223d1930
>
> Hi Sampad,
>
> It looks like you've found a hole in our testing ;). We don't compile 
> HSAIL regularly, and it looks like some bugs have worked their way in.
> Tony, do you think you, or someone else that's familiar with the GPU 
> model could take a look?
>
> Cheers,
> Jason
>
> On Thu, Aug 16, 2018 at 8:36 AM Sampad Mohapatra  su...@psu.edu>> wrote:
> Hi Gabe,
>
> I am building on a 64 bit cluster.
>
> I might have found the reasons for the issues:
>
> (1) There is no function "const_iterator find(Addr r) const" in 
> src/base/addr_range_map.hh.
>
> (2) In src/base/types.hh, struct TypedAtomicOpFunctor has a pure 
> virtual function "clone()". This struct is the base for a
>
>  lot of GPU op classes in src/gpu-compute/gpu_dyn_inst.hh. But 
> these classes don't define clone(). This results in
>  the errors I mentioned in (2).
>
> Sampad
>
> On Tue, Aug 14, 2018 at 2:26 PM Gabe Black wrote:
> > I wonder if you're building on a 32 bit machine? It could be that
> somebody
> > made an assumption about how big certain types are, and some 
> > function definitions which normally turn out to be the same thing 
> > are different if certain types are no longer equivalent. That would 
> > be my gut reaction to the second problem. Maybe add "override" in 
> > places where a virtual
> function
> > is being overridden in the GPU code related to the error? I bet the 
> > compiler complains about at least one of them.
>
> > Gabe
>
> On Tue, Aug 14, 2018 at 5:46 AM Sampad Mohapatra  su...@psu.edu>> wrote:
>
> > I have tried building with both gcc 7.1 and gcc 5.4 and get the same 
> > set
> of
> > errors.
> > I am also using scons v3.1, Python 2.7.13, swig 3.0.12. All of these 
> > were built from source.
> >
> > I use a cluster running Red Hat 4.4.7-18  (Linux version 
> > 2.6.32-696.6.3.el6.x86_64).
> >
> > Thanks
> > Sampad
> >
> >
> >
> > On Tue, Aug 14, 2018 at 5:46 AM Ciro Santilli 
> >  <mailto:ciro.santi...@gmail.com>>
> > wrote:
> >
> > > What is your compiler version?
> > >
> > > On Tue, Aug 14, 2018 at 12:53 AM, Sampad Mohapatra  <mailto:su...@psu.edu>&g

Re: [gem5-dev] Gem5 Compile issue : Commit : e02ec0c24d56bce4a0d8636a340e15cd223d1930

[Gutierrez, Anthony]

Sampad, are you trying to run our GPU model? If so, HSAIL is deprecated. We 
released an updated version of our GPU simulator at 
gem5.googlesource.com/amd/gem5 branch agutierr/master-gcn3-staging. I recommend 
you starting with that.

I don’t think anybody at AMD will have time to look into HSAIL bugs for the 
time being, but doesn’t the current tester test at least 1 GPU program (gpu 
hello)? How did the changes get by the tester?

If you encounter issues with our GCN3 model, you can notify us through the gem5 
mailing list.

From: Jason Lowe-Power 
Sent: Thursday, August 16, 2018 9:46 AM
To: gem5 Developer List ; Gutierrez, Anthony 

Subject: Re: [gem5-dev] Gem5 Compile issue : Commit : 
e02ec0c24d56bce4a0d8636a340e15cd223d1930

Hi Sampad,

It looks like you've found a hole in our testing ;). We don't compile HSAIL 
regularly, and it looks like some bugs have worked their way in. Tony, do you 
think you, or someone else that's familiar with the GPU model could take a look?

Cheers,
Jason

On Thu, Aug 16, 2018 at 8:36 AM Sampad Mohapatra 
mailto:su...@psu.edu>> wrote:
Hi Gabe,

I am building on a 64 bit cluster.

I might have found the reasons for the issues:

(1) There is no function "const_iterator find(Addr r) const" in
src/base/addr_range_map.hh.

(2) In src/base/types.hh, struct TypedAtomicOpFunctor has a pure
virtual function "clone()". This struct is the base for a

 lot of GPU op classes in src/gpu-compute/gpu_dyn_inst.hh. But
these classes don't define clone(). This results in
 the errors I mentioned in (2).

Sampad

On Tue, Aug 14, 2018 at 2:26 PM Gabe Black wrote:
> I wonder if you're building on a 32 bit machine? It could be that somebody
> made an assumption about how big certain types are, and some function
> definitions which normally turn out to be the same thing are different if
> certain types are no longer equivalent. That would be my gut reaction to
> the second problem. Maybe add "override" in places where a virtual function
> is being overridden in the GPU code related to the error? I bet the
> compiler complains about at least one of them.

> Gabe

On Tue, Aug 14, 2018 at 5:46 AM Sampad Mohapatra 
mailto:su...@psu.edu>> wrote:

> I have tried building with both gcc 7.1 and gcc 5.4 and get the same set of
> errors.
> I am also using scons v3.1, Python 2.7.13, swig 3.0.12. All of these were
> built from source.
>
> I use a cluster running Red Hat 4.4.7-18  (Linux version
> 2.6.32-696.6.3.el6.x86_64).
>
> Thanks
> Sampad
>
>
>
> On Tue, Aug 14, 2018 at 5:46 AM Ciro Santilli 
> mailto:ciro.santi...@gmail.com>>
> wrote:
>
> > What is your compiler version?
> >
> > On Tue, Aug 14, 2018 at 12:53 AM, Sampad Mohapatra 
> > mailto:su...@psu.edu>>
> wrote:
> >
> > > Hi All,
> > >
> > > I am facing compile issues while trying to compile
> > > commit e02ec0c24d56bce4a0d8636a340e15cd223d1930 .
> > > There are two types of errors in the Gem5 source:
> > >
> > > (1)  *no matching function for call to : find(uint64_t&)*
> > >
> > > build/HSAIL_X86/gpu-compute/hsail_code.cc: In member function
> > > 'StorageElement* StorageSpace::findSymbol(uint64_t)':
> > > build/HSAIL_X86/gpu-compute/hsail_code.cc:336:41: error: no matching
> > > function for call to 'AddrRangeMap::find(uint64_t&)'
> > >  auto se = elements_by_addr.find(addr);
> > >  ^
> > > In file included from build/HSAIL_X86/gpu-compute/hsail_code.hh:47:0,
> > >  from build/HSAIL_X86/gpu-compute/hsail_code.cc:36:
> > > build/HSAIL_X86/base/addr_range_map.hh:225:5: note: candidate:
> > > AddrRangeMap::const_iterator AddrRangeMap > > max_cache_size>::find(const AddrRange&, std::function)
> > > const [with V = StorageElement*; int max_cache_size = 0;
> AddrRangeMap > > max_cache_size>::const_iterator =
> > > std::_Rb_tree_const_iterator StorageElement*>
> > > >]
> > >  find(const AddrRange &r, std::function
> cond)
> > > const
> > >  ^
> > > build/HSAIL_X86/base/addr_range_map.hh:225:5: note:   candidate
> expects 2
> > > arguments, 1 provided
> > >
> > >
> > > (2) *Multiple issues due to object creation from virtual classes. For
> > > example:*
> > >
> > > In file included from
> > build/HSAIL_X86/gpu-compute/gpu_static_inst.hh:53:0,
> > >  from
> > > build/HSAIL_X86/arch/hsail/insts/gpu_static_inst.hh:46,
> > >  from build/HSAIL_X86/arch/hsail/insts/branch.hh:39,

Re: [gem5-dev] How to increase the default CU counts in GCN_X86 gem5-apu?

[Gutierrez, Anthony]

That seems right, Tsung. The idea is that the # of CUs and the objects that 
interact with, or contain, the CUs must match certain ratios.

Can you post your changes as a full patch so I can review them?

-Tony

-Original Message-
From: gem5-dev  On Behalf Of Tsungtai Yeh
Sent: Wednesday, August 08, 2018 5:22 AM
To: gem5-dev@gem5.org
Subject: Re: [gem5-dev] How to increase the default CU counts in GCN_X86 
gem5-apu?

The default value of the following options is 4. You have to change the default 
value to the number that is greater than 4 to scale CU count.

parser.add_option("-u", "--num-compute-units", type="int", default=32,

  help="number of GPU compute units") 
parser.add_option("--cu-per-sqc", type="int", default=32, help="number of CUs" \

  "sharing an SQC (icache, and thus icache TLB)") 
parser.add_option("--simds-per-cu", type="int", default=32, help="SIMD units" \
  "per CU")
parser.add_option('--cu-per-sa', type='int', default=32,
  help='Number of CUs per shader array. This must be a '

  'multiple of options.cu-per-sqc and options.cu-per-scalar')

These four options have to be changed at the same time. Otherwise, the 
segmentation fault will be raised.

From: Tsungtai Yeh
Sent: Wednesday, August 8, 2018 8:17:48 AM
To: gem5-dev@gem5.org
Subject: Re: [gem5-dev] How to increase the default CU counts in GCN_X86 
gem5-apu?


The default value of the following options is 4. You have to change the default 
value to the number that is greater than 4 to scale CU count.


parser.add_option("-u", "--num-compute-units", type="int", default=32,

  help="number of GPU compute units")

parser.add_option("--cu-per-sqc", type="int", default=32, help="number of CUs" \

  "sharing an SQC (icache, and thus icache TLB)")

parser.add_option("--simds-per-cu", type="int", default=32, help="SIMD units" \

  "per CU")

parser.add_option('--cu-per-sa', type='int', default=32,

  help='Number of CUs per shader array. This must be a '

  'multiple of options.cu-per-sqc and options.cu-per-scalar')



From: Tsungtai Yeh
Sent: Monday, August 6, 2018 9:19:14 AM
To: gem5-dev@gem5.org
Subject: Re: [gem5-dev] How to increase the default CU counts in GCN_X86 
gem5-apu?


I found I have to change the following options to increase the number of CUs in 
GCN_X86.

--num-compute-units

--cu-per-sqc

--cu-per-scalar-cache

--simds-per-cu

--cu-per-sa




From: Tsungtai Yeh
Sent: Saturday, July 28, 2018 8:40:30 PM
To: gem5-dev@gem5.org
Subject: Re: [gem5-dev] How to increase the default CU counts in GCN_X86 
gem5-apu?

I changed the default value of “—num-compute-units” to 8 in apu_se.py. I still 
got the segmentation fault. The following is the trace from gem5 simulation. 
The 8 CUs are initialized successfully, but get the failure during the 
instruction fetching stage. — Tsung Tai parser.add_option("-u", 
"--num-compute-units", type="int", default=8,
  help="number of GPU compute units")

51620963000: system.cpu2.CUs0: trueWgSize[0] =  256
51620963000: system.cpu2.CUs0: trueWgSize[1] =  1
51620963000: system.cpu2.CUs0: trueWgSize[2] =  1
51620963000: system.cpu2.CUs0: trueWgSizeTotal =  256
51620963000: system.cpu2.CUs0: Free WF slots =  36, Mapped WFs = 0, 
VGPR Availability = 0, SGPR Availability = 0
51620963000: system.cpu2.CUs1: trueWgSize[0] =  256
51620963000: system.cpu2.CUs1: trueWgSize[1] =  1
51620963000: system.cpu2.CUs1: trueWgSize[2] =  1
51620963000: system.cpu2.CUs1: trueWgSizeTotal =  256
51620963000: system.cpu2.CUs1: Free WF slots =  36, Mapped WFs = 0, 
VGPR Availability = 0, SGPR Availability = 0
51620963000: system.cpu2.CUs2: trueWgSize[0] =  256
51620963000: system.cpu2.CUs2: trueWgSize[1] =  1
51620963000: system.cpu2.CUs2: trueWgSize[2] =  1
51620963000: system.cpu2.CUs2: trueWgSizeTotal =  256
51620963000: system.cpu2.CUs2: Free WF slots =  36, Mapped WFs = 0, 
VGPR Availability = 0, SGPR Availability = 0
51620963000: system.cpu2.CUs3: trueWgSize[0] =  256
51620963000: system.cpu2.CUs3: trueWgSize[1] =  1
51620963000: system.cpu2.CUs3: trueWgSize[2] =  1
51620963000: system.cpu2.CUs3: trueWgSizeTotal =  256
51620963000: system.cpu2.CUs3: Free WF slots =  36, Mapped WFs = 0, 
VGPR Availability = 0, SGPR Availability = 0
51620963000: system.cpu2.CUs4: trueWgSize[0] =  256
51620963000: system.cpu2.CUs4: trueWgSize[1] =  1
51620963000: system.cpu2.CUs4: trueWgSize[2] =  1
51620963000: system.cpu2.CUs4: trueWgSizeTotal =  256
51620963000: system.cpu2.CUs4: Free WF slots =  36, Mapped WFs = 0, 
VGPR Availability = 0, SGPR Availability = 0
51620963000: system.cpu2.CUs5: trueWgSize[0] =  256
51620963000: system.cpu2.CUs5: trueWgSize[1] =  1
51620963000: system.cpu2.CUs5: trueWgSize

Re: [gem5-dev] How to increase the default CU counts in GCN_X86 gem5-apu?

[Gutierrez, Anthony]

It looks like the number of CUs is being set to 8. The simulator is segfaulting 
for some other reason, and you haven't shown enough info to know why it is 
segfaulting.

-Original Message-
From: gem5-dev  On Behalf Of Tsungtai Yeh
Sent: Saturday, July 28, 2018 5:41 PM
To: gem5-dev@gem5.org
Subject: Re: [gem5-dev] How to increase the default CU counts in GCN_X86 
gem5-apu?

I changed the default value of “—num-compute-units” to 8 in apu_se.py. I still 
got the segmentation fault. The following is the trace from gem5 simulation. 
The 8 CUs are initialized successfully, but get the failure during the 
instruction fetching stage. — Tsung Tai parser.add_option("-u", 
"--num-compute-units", type="int", default=8,
  help="number of GPU compute units")

51620963000: system.cpu2.CUs0: trueWgSize[0] =  256
51620963000: system.cpu2.CUs0: trueWgSize[1] =  1
51620963000: system.cpu2.CUs0: trueWgSize[2] =  1
51620963000: system.cpu2.CUs0: trueWgSizeTotal =  256
51620963000: system.cpu2.CUs0: Free WF slots =  36, Mapped WFs = 0, 
VGPR Availability = 0, SGPR Availability = 0
51620963000: system.cpu2.CUs1: trueWgSize[0] =  256
51620963000: system.cpu2.CUs1: trueWgSize[1] =  1
51620963000: system.cpu2.CUs1: trueWgSize[2] =  1
51620963000: system.cpu2.CUs1: trueWgSizeTotal =  256
51620963000: system.cpu2.CUs1: Free WF slots =  36, Mapped WFs = 0, 
VGPR Availability = 0, SGPR Availability = 0
51620963000: system.cpu2.CUs2: trueWgSize[0] =  256
51620963000: system.cpu2.CUs2: trueWgSize[1] =  1
51620963000: system.cpu2.CUs2: trueWgSize[2] =  1
51620963000: system.cpu2.CUs2: trueWgSizeTotal =  256
51620963000: system.cpu2.CUs2: Free WF slots =  36, Mapped WFs = 0, 
VGPR Availability = 0, SGPR Availability = 0
51620963000: system.cpu2.CUs3: trueWgSize[0] =  256
51620963000: system.cpu2.CUs3: trueWgSize[1] =  1
51620963000: system.cpu2.CUs3: trueWgSize[2] =  1
51620963000: system.cpu2.CUs3: trueWgSizeTotal =  256
51620963000: system.cpu2.CUs3: Free WF slots =  36, Mapped WFs = 0, 
VGPR Availability = 0, SGPR Availability = 0
51620963000: system.cpu2.CUs4: trueWgSize[0] =  256
51620963000: system.cpu2.CUs4: trueWgSize[1] =  1
51620963000: system.cpu2.CUs4: trueWgSize[2] =  1
51620963000: system.cpu2.CUs4: trueWgSizeTotal =  256
51620963000: system.cpu2.CUs4: Free WF slots =  36, Mapped WFs = 0, 
VGPR Availability = 0, SGPR Availability = 0
51620963000: system.cpu2.CUs5: trueWgSize[0] =  256
51620963000: system.cpu2.CUs5: trueWgSize[1] =  1
51620963000: system.cpu2.CUs5: trueWgSize[2] =  1
51620963000: system.cpu2.CUs5: trueWgSizeTotal =  256
51620963000: system.cpu2.CUs5: Free WF slots =  36, Mapped WFs = 0, 
VGPR Availability = 0, SGPR Availability = 0
51620963000: system.cpu2.CUs6: trueWgSize[0] =  256
51620963000: system.cpu2.CUs6: trueWgSize[1] =  1
51620963000: system.cpu2.CUs6: trueWgSize[2] =  1
51620963000: system.cpu2.CUs6: trueWgSizeTotal =  256
51620963000: system.cpu2.CUs6: Free WF slots =  36, Mapped WFs = 0, 
VGPR Availability = 0, SGPR Availability = 0
51620963000: system.cpu2.CUs7: trueWgSize[0] =  256
51620963000: system.cpu2.CUs7: trueWgSize[1] =  1
51620963000: system.cpu2.CUs7: trueWgSize[2] =  1
51620963000: system.cpu2.CUs7: trueWgSizeTotal =  256
51620963000: system.cpu2.CUs7: Free WF slots =  36, Mapped WFs = 0, 
VGPR Availability = 0, SGPR Availability = 0
51620963000: system.cpu0.workload.drivers.device.dispatcher: kernel 0 failed to 
launch
51620963000: system.cpu0.workload.drivers.device.dispatcher: Returning 0 Kernels
51620964000: global: WF[0][0]: Id28 reserved fetch buffer entry for PC = 
0x7ffeebde9100
51620964000: global: CU7: WF[0][0]: Id28: Initiate fetch from pc: 
140732855652608 0x7ffeebde9100
51620964000: global: CU7: WF[0][0]: Initiating fetch translation: 0x7ffeebde9100
gem5 has encountered a segmentation fault!

From: Tsungtai Yeh
Sent: Friday, July 27, 2018 7:20:55 AM
To: gem5-dev@gem5.org
Cc: anthony.gutier...@amd.com
Subject: [gem5-dev] How to increase the default CU counts in GCN_X86 gem5-apu?


I tried to increase the CU counts to 32 in the gem5-apu. However, I found I 
could not only increase "--num-compute-units" default count (4). Do you know 
any other parameters I also need to change when increasing the CU counts? Thank 
you.
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] How to increase the default CU counts in GCN_X86 gem5-apu?

[Gutierrez, Anthony]

Looking at apu_se.py, it seems that is the only option to set # of CUs. Does it 
not work for you? From that file, it seems like it should be the only option 
you need.

From: Tsungtai Yeh 
Sent: Friday, July 27, 2018 4:21 AM
To: gem5-dev@gem5.org
Cc: Gutierrez, Anthony 
Subject: [gem5-dev] How to increase the default CU counts in GCN_X86 gem5-apu?


I tried to increase the CU counts to 32 in the gem5-apu. However, I found I 
could not only increase "--num-compute-units" default count (4). Do you know 
any other parameters I also need to change when increasing the CU counts? Thank 
you.
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Encountered unimplemented GCN3 instruction: v_div_scale_f32

[Gutierrez, Anthony]

I've posted the change that adds v_div_scale_f32 here:

https://gem5-review.googlesource.com/c/amd/gem5/+/11889

From: Tsungtai Yeh 
Sent: Friday, July 27, 2018 4:24 AM
To: gem5-dev@gem5.org
Cc: Gutierrez, Anthony ; Sinclair, Matthew 

Subject: [gem5-dev] Encountered unimplemented GCN3 instruction: v_div_scale_f32


v_div_scale_f32 has not been implemented in GCN3_X86 yet. Could someone try to 
add it in? Thank you?

fatal: Encountered unimplemented GCN3 instruction: v_div_scale_f32
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Error in running gpu-hello on GCN3_X86

[Gutierrez, Anthony]

Xianwei has posted some changes to fix the problem. The one most directly 
related to your issue has been merged. You may need to cherry pick the other.

-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Sanchari Sen
Sent: Thursday, June 28, 2018 6:47 AM
To: gem5-dev@gem5.org
Subject: Re: [gem5-dev] Error in running gpu-hello on GCN3_X86

Thank you for the clarification. Commenting out line 249 in apu_se.py allows me 
to avoid the above error but as you pointed out, its not really helpful as I 
need a separate binary altogether.

Sanchari

On Wed, Jun 27, 2018 at 5:24 PM Sanchari Sen  wrote:

> Hi Tony and Tuan,
>
> I have cloned the agutierr/master-gcn3-staging branch of gem5  
> available on "https://gem5.googlesource.com/amd/gem5/"; and have built 
> GCN3_X86/gem5.opt using the default GCN3_X86 file in build_opts 
> folder. I am trying to run gpu-hello program on it using the following 
> command
>
> "./build/GCN3_X86/gem5.opt configs/example/apu_se.py -c 
> tests/test-progs/gpu-hello/bin/x86/linux/gpu-hello"
>
> The gpu-hello binary is the default binary present in the branch. I 
> get the following error on running the above command.
>
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "gem5/src/python/m5/main.py", line 435, in main
> exec filecode in scope
>   File "configs/example/apu_se.py", line 249, in 
> shader.impl_kern_boundary_sync = True
>   File "gem5/src/python/m5/SimObject.py", line 1175, in __setattr__
> % (self.__class__.__name__, attr)
> AttributeError: Class Shader has no parameter impl_kern_boundary_sync
>
> I would really appreciate any help from you on this.
>
> Thanks in advance,
> Sanchari
>
>
>

--
Sanchari Sen
Graduate Student
Department of Electrical and Computer Engineering Purdue University 
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Error in running gpu-hello on GCN3_X86

[Gutierrez, Anthony]

That binary is for HSAIL, so it will not run for GCN3. The model currently only 
supports GCN3 ISA binaries and host apps which use the ROCm stack.

The config issue is due to this change: 
https://gem5.googlesource.com/amd/gem5/+/a0d42e05f700048b3a77d673ca992e227ac982e0,
 which changed those params, but didn't update the config script.

I can ask the author of the above change to fix the config issue, but you will 
still need to build the ROCm stack and compile benchmarks for GCN3.

-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Sanchari Sen
Sent: Wednesday, June 27, 2018 2:24 PM
To: gem5-dev@gem5.org
Subject: [gem5-dev] Error in running gpu-hello on GCN3_X86

Hi Tony and Tuan,

I have cloned the agutierr/master-gcn3-staging branch of gem5  available on 
"https://gem5.googlesource.com/amd/gem5/"; and have built GCN3_X86/gem5.opt 
using the default GCN3_X86 file in build_opts folder. I am trying to run 
gpu-hello program on it using the following command

"./build/GCN3_X86/gem5.opt configs/example/apu_se.py -c 
tests/test-progs/gpu-hello/bin/x86/linux/gpu-hello"

The gpu-hello binary is the default binary present in the branch. I get the 
following error on running the above command.

Traceback (most recent call last):
  File "", line 1, in 
  File "gem5/src/python/m5/main.py", line 435, in main
exec filecode in scope
  File "configs/example/apu_se.py", line 249, in 
shader.impl_kern_boundary_sync = True
  File "gem5/src/python/m5/SimObject.py", line 1175, in __setattr__
% (self.__class__.__name__, attr)
AttributeError: Class Shader has no parameter impl_kern_boundary_sync

I would really appreciate any help from you on this.

Thanks in advance,
Sanchari
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Question about vendor-specific x86 CPUID functions

[Gutierrez, Anthony]

"This might be a place where it would make sense to somehow bridge between 
python and c++ and let the config specialize some sort of function or dict or 
tree of dicts or whatever which decode what CPUID function is being requested."

Can you expand on the details of this statement a bit more?

My initial thoughts were that it would not be so hard to specialize the CPUID 
function because there are only 2 flavors. I was thinking we could move the 
functionality provided by doCpuid() into its own class and make it a Param of 
the X86 ISA sim object. Or, simply give the ISA object a "flavor" param that 
will execute the correct CPU ID functionality based on the flavor of the ISA. 
Although, if I understand what you're describing at a high-level, it would be 
more automated/integrated with Scons, which may be good.

The bigger issue to me is how to properly serve some of the CPUID functions, 
like the functions that describe the cache hierarchy. It didn't seem to be that 
easy to access all of that info from doCpuid() currently, although much of it 
may be, in one way or another, accessible through the thread context.

-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Gabe Black
Sent: Thursday, May 03, 2018 6:26 PM
To: gem5 Developer List 
Subject: Re: [gem5-dev] Question about vendor-specific x86 CPUID functions

Yeah, that's a good question, and I don't have a specific plan for how to 
handle it. Since gem5 nominally simulates some sort of abstract x86 CPU which 
isn't really Intel or AMD or anybody (although probably most like AMD because 
those are the manuals I used), it sits in a weird area where code written for 
the real world probably doesn't know quite what to do with it.

This might be a place where it would make sense to somehow bridge between 
python and c++ and let the config specialize some sort of function or dict or 
tree of dicts or whatever which decode what CPUID function is being requested. 
We should consider how much interaction there would need to be between a system 
like that and the c++ side of the hardware, or if, for instance, it could 
somehow crawl the SimObject hierarchy in python to find out what values to 
return for, say, cache sizes, etc. I've been playing around with the interface 
between c++ and python, and while it's still a bit mysterious still, it's 
actually pretty powerful and fairly straightforward to use.

With that sort of setup, if you wanted to make it look like a particular model 
of AMD cpu or Intel CPU or your own magic CPU, or add in some additional CPUID 
field for some reason, all of that would be relatively accessible and easier to 
customize on a per CPU basis.

What do you think?

Gabe

On Thu, May 3, 2018 at 2:55 PM, Gutierrez, Anthony < anthony.gutier...@amd.com> 
wrote:

> This question is mostly for Gabe. In the ROCm runtime we see some 
> inline asm for specific CPUID functions. They first use CPUID to 
> determine the name string for the processor, and when it seems the "M5 
> Simulator" as the vendor it defaults to Intel and sends along the 
> CPUID request with the Intel-specific ID for cache config descriptors. 
> The ID used by Intel is different than is used by AMD for the same function.
> I am just wondering what your thoughts are about implementing these 
> functions. Do we implement the CPUID functions for only one vendor? Is 
> there a way to make it configurable?
>
> Currently I am not bothering to implement it, I am simply returning 
> {0x0, 0x0, 0x0, 0x0} and issuing a warn (in cupid.cc), but I still 
> need to add the particular ID to the StandardCpuidFunction enums in 
> order for it to be considered in the switch statement.
> ___
> gem5-dev mailing list
> gem5-dev@gem5.org
> http://m5sim.org/mailman/listinfo/gem5-dev
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] Question about vendor-specific x86 CPUID functions

[Gutierrez, Anthony]

This question is mostly for Gabe. In the ROCm runtime we see some inline asm 
for specific CPUID functions. They first use CPUID to determine the name string 
for the processor, and when it seems the "M5 Simulator" as the vendor it 
defaults to Intel and sends along the CPUID request with the Intel-specific ID 
for cache config descriptors. The ID used by Intel is different than is used by 
AMD for the same function.
I am just wondering what your thoughts are about implementing these functions. 
Do we implement the CPUID functions for only one vendor? Is there a way to make 
it configurable?

Currently I am not bothering to implement it, I am simply returning {0x0, 0x0, 
0x0, 0x0} and issuing a warn (in cupid.cc), but I still need to add the 
particular ID to the StandardCpuidFunction enums in order for it to be 
considered in the switch statement.
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] X86 Divide-Error when using

[Gutierrez, Anthony]

We've started experiencing some heisenbugs in our benchmarks that use  
to generate input data randomly. It's been a bit painful to get a trace, as 
that seems to perturb things enough such that the bug won't trigger. Based on 
what we know, however, we suspect that the below unimplemented instructions 
should be manipulating some FP registers (e.g., ST). The FP registers do not 
seem to be initialized in initCPU(), and therefore we hypothesize that in some 
cases, for example when the values happen to be 0, the denominator has a value 
that can cause the div 0 fault.

The fault is always preceded by this sequence of unimplemented instruction 
warnings, then finally the simulation fails with the following error on a div 
instruction:

warn: instruction 'fsubrp' unimplemented
warn: instruction 'fxam' unimplemented
warn: instruction 'fcomp' unimplemented
warn: instruction 'fyl2xp1' unimplemented
warn: instruction 'fdivrp' unimplemented
warn: instruction 'fistp' unimplemented
panic: fault (Divide-Error) detected @ PC (0x400fad=>0x400fb1).(1=>2)

This can be reproduced on master (fairly reliably) with the following 
microbenchmark:

scons -jN -sQ ./build/X86/gem5.opt
./build/X86/gem5.opt configs/example/se.py -c /path/to/benchmark/binary

Build the following with g++ 5.4.0, flags are -std=c++11.

#include 
#include 
#include 

using namespace std;

constexpr int VEC_ELEMS = 64;

struct Point2D
{
float x;
float y;
};

int main(int argc, char *argv[])
{
uniform_real_distribution rng_dist(-1.0, 1.0);
cout << "here" << endl;

mt19937 rng;
array vec;

for (int i = 0; i < VEC_ELEMS; ++i) {
vec[i].x = rng_dist(rng);
vec[i].y = rng_dist(rng);

cout << "vec[" << i << "].x = " << vec[i].x << endl;
cout << "vec[" << i << "].y = " << vec[i].y << endl;
}
Return 0;
}
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Using branching in gem5 public

[Gutierrez, Anthony]

Thanks, Andreas. I'll take a look.

-Original Message-
From: Andreas Sandberg [mailto:andreas.sandb...@arm.com] 
Sent: Tuesday, December 19, 2017 9:22 AM
To: Gutierrez, Anthony ; gem5 Developer List 

Subject: Re: [gem5-dev] Using branching in gem5 public

Hi Tony,

Both you and Brad should have the necessary admin bits to create new projects. 
You can create a new project from the review system. The parent directory 
('arm' in our case) should be created with 'Only serve as parent for other 
projects' set and inherit permissions from All-Projects. You can then change 
the configuration in your parent project to suit your needs. A small gotcha is 
that you shouldn't include a leading slash in the project name (e.g., our gem5 
repo is called arm/gem5).

We ended up adding a separate group of users that have rights to push directly 
to the repo and require a member of that group to set the maintainer flags when 
other users submit code. You can use our config [1] as a starting point if you 
need something similar.

Cheers,
Andreas

[1] https://gem5.googlesource.com/arm/+/refs/meta/config


On 19/12/2017 17:06, Gutierrez, Anthony wrote:
> Hi Andreas,
>
> This all makes sense, and I think for our purposes a separate AMD/ repo 
> similar to ARM's setup (option 1 as you say) would be perfect for us. Do you 
> have permissions to create a new repo for AMD? Or can you give me permissions 
> to do so?
>
> Thanks,
> Tony
>
> -Original Message-
> From: Andreas Sandberg [mailto:andreas.sandb...@arm.com]
> Sent: Thursday, December 14, 2017 10:01 AM
> To: gem5 Developer List ; Gutierrez, Anthony 
> 
> Subject: Re: [gem5-dev] Using branching in gem5 public
>
> Hi Tony,
>
> I'm generally all for using branches, we use them extensively internally. 
> IMO, the options we have in gerrit for what both of us are trying to 
> accomplish, us with SVE and you with the GPU, are as follows:
>
> 1. We create different repositories per user / institution and push between 
> repos.
> 2. We create branch "namespaces" in the main repo (e.g., arm/**, 
> amd/**,
> users/a.hacker/**)
>
> Gerrit is able to handle permissions and policies (e.g., whether some users 
> can push without review and who is allowed to review) per branch as well as 
> per repo. There are some differences in what you can do and how you do it, 
> but in general, they are roughly equivalent when it comes to permissions.
>
> We obviously already went with option one. The main benefit, as I see it, of 
> this option is that we don't pollute the branch namespace with pre-release 
> changes. I would argue that this option scales a bit better in terms of 
> usability as well. Once you start having a lot of working branches, cloning 
> the repo will be pretty annoying. The Linux uses a similar strategy and most 
> well-known kernel devs have their own repos on git.kernel.org and Linus 
> curates the master repo.
>
> Cheers,
> Andreas
>
> On 14/12/2017 16:29, Gutierrez, Anthony wrote:
>> Hi All,
>>
>> I have a question about using branches in the mainline gem5 repo. I see ARM 
>> have a separate repo here: 
>> https://gem5-review.googlesource.com/admin/projects/arm/gem5. It is used for 
>> staging ARM features under development. At AMD we would like to do something 
>> similar, as we have some significant changes to the GPU model we would like 
>> to push out to the public. We were thinking about doing so with branches, 
>> and were wondering what others thought about branches? I'm sure it's been 
>> discussed somewhat in the past, but I can't find much searching through old 
>> posts.
>>
>> What I was thinking would be to have institutional branches, like AMD or ARM 
>> branches, and perhaps users from those institutions who are also gem5 
>> maintainers could have user specific branches. We use branches a lot 
>> internally and find them extremely useful. So I'd like to get a better idea 
>> why there is an aversion to using branches on the public tree, if there is 
>> such an aversion.
>>
>> -Tony
>> ___
>> gem5-dev mailing list
>> gem5-dev@gem5.org
>> http://m5sim.org/mailman/listinfo/gem5-dev
> IMPORTANT NOTICE: The contents of this email and any attachments are 
> confidential and may also be privileged. If you are not the intended 
> recipient, please notify the sender immediately and do not disclose the 
> contents to any other person, use it for any purpose, or store or copy the 
> information in any medium. Thank you.

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Using branching in gem5 public

[Gutierrez, Anthony]

Hi Andreas,

This all makes sense, and I think for our purposes a separate AMD/ repo similar 
to ARM's setup (option 1 as you say) would be perfect for us. Do you have 
permissions to create a new repo for AMD? Or can you give me permissions to do 
so?

Thanks,
Tony

-Original Message-
From: Andreas Sandberg [mailto:andreas.sandb...@arm.com] 
Sent: Thursday, December 14, 2017 10:01 AM
To: gem5 Developer List ; Gutierrez, Anthony 

Subject: Re: [gem5-dev] Using branching in gem5 public

Hi Tony,

I'm generally all for using branches, we use them extensively internally. IMO, 
the options we have in gerrit for what both of us are trying to accomplish, us 
with SVE and you with the GPU, are as follows:

1. We create different repositories per user / institution and push between 
repos.
2. We create branch "namespaces" in the main repo (e.g., arm/**, amd/**,
users/a.hacker/**)

Gerrit is able to handle permissions and policies (e.g., whether some users can 
push without review and who is allowed to review) per branch as well as per 
repo. There are some differences in what you can do and how you do it, but in 
general, they are roughly equivalent when it comes to permissions.

We obviously already went with option one. The main benefit, as I see it, of 
this option is that we don't pollute the branch namespace with pre-release 
changes. I would argue that this option scales a bit better in terms of 
usability as well. Once you start having a lot of working branches, cloning the 
repo will be pretty annoying. The Linux uses a similar strategy and most 
well-known kernel devs have their own repos on git.kernel.org and Linus curates 
the master repo.

Cheers,
Andreas

On 14/12/2017 16:29, Gutierrez, Anthony wrote:
> Hi All,
>
> I have a question about using branches in the mainline gem5 repo. I see ARM 
> have a separate repo here: 
> https://gem5-review.googlesource.com/admin/projects/arm/gem5. It is used for 
> staging ARM features under development. At AMD we would like to do something 
> similar, as we have some significant changes to the GPU model we would like 
> to push out to the public. We were thinking about doing so with branches, and 
> were wondering what others thought about branches? I'm sure it's been 
> discussed somewhat in the past, but I can't find much searching through old 
> posts.
>
> What I was thinking would be to have institutional branches, like AMD or ARM 
> branches, and perhaps users from those institutions who are also gem5 
> maintainers could have user specific branches. We use branches a lot 
> internally and find them extremely useful. So I'd like to get a better idea 
> why there is an aversion to using branches on the public tree, if there is 
> such an aversion.
>
> -Tony
> ___
> gem5-dev mailing list
> gem5-dev@gem5.org
> http://m5sim.org/mailman/listinfo/gem5-dev

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Using branching in gem5 public

[Gutierrez, Anthony]

Hi Jason,

Our overall goal is to merge our changes into master, and we already keep our 
branches synced with master weekly. The basic idea here is to be able to 
iterate on code in the public, collaborate with users in the public, and 
release it earlier without having to go through the full review process. 
Hopefully users will find the "pre-production" code useful, and maybe even help 
contribute. This is our flow currently, but it's all done internally. And it 
doesn't have to be branches, based on Andreas' reply I think a separate AMD 
repo will serve just fine.

Thanks,
Tony

-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Jason Lowe-Power
Sent: Thursday, December 14, 2017 9:58 AM
To: gem5 Developer List 
Subject: Re: [gem5-dev] Using branching in gem5 public

Hey Tony,

A few thoughts:

I think it's a good idea to post pre-production code publicly. This gives other 
developers a chance to see and comment on the design (well, it *could*), and, 
more importantly, it gives users access to new features quickly.

There is one potential downside to the above: Less motivation to clean up code 
and push it into the mainline. I don't know how large of a downside this is, 
but from my personal experience with gem5-gpu, it's likely to happen. Merging 
gem5-gpu with mainline gem5 is *a lot* of work, and since we published our gem5 
changes in another repo we never felt the need to undertake it. This was bad 
for the long-term viability of gem5-gpu and gem5-gpu's users.

As far as specifically branches go, I think I would prefer to see separate 
repos like the arm/gem5 repo (or my github repo). I worry about two things when 
bringing branches into public/gem5.
1. We will have too many branches and it will be difficult to manage 2. 
Configuring gerrit so code-review is only required on master and whenever 
others post changes to any other branch no one gets emailed.

The second concern may be solvable (I have no idea), and the first concern may 
not be warranted.

I completely agree that branches are great (see my github repo, for instance. I 
have 10-20 branches personally). However, one thing I have discovered is that 
when working in a group you have to be *very* careful about how branches are 
managed across the group (e.g., when and who is allowed to rebase).

I think using separate repositories gives most of the benefits of branches 
(simple to pull changes from others and see others work, better organization, 
etc) without the downsides.

I'm open to other points of view, of course!

Cheers,
Jason

On Thu, Dec 14, 2017 at 8:30 AM Gutierrez, Anthony < anthony.gutier...@amd.com> 
wrote:

> Hi All,
>
> I have a question about using branches in the mainline gem5 repo. I 
> see ARM have a separate repo here:
> https://gem5-review.googlesource.com/admin/projects/arm/gem5. It is 
> used for staging ARM features under development. At AMD we would like 
> to do something similar, as we have some significant changes to the 
> GPU model we would like to push out to the public. We were thinking 
> about doing so with branches, and were wondering what others thought 
> about branches? I'm sure it's been discussed somewhat in the past, but 
> I can't find much searching through old posts.
>
> What I was thinking would be to have institutional branches, like AMD 
> or ARM branches, and perhaps users from those institutions who are 
> also gem5 maintainers could have user specific branches. We use 
> branches a lot internally and find them extremely useful. So I'd like 
> to get a better idea why there is an aversion to using branches on the 
> public tree, if there is such an aversion.
>
> -Tony
> ___
> gem5-dev mailing list
> gem5-dev@gem5.org
> http://m5sim.org/mailman/listinfo/gem5-dev
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] Using branching in gem5 public

[Gutierrez, Anthony]

Hi All,

I have a question about using branches in the mainline gem5 repo. I see ARM 
have a separate repo here: 
https://gem5-review.googlesource.com/admin/projects/arm/gem5. It is used for 
staging ARM features under development. At AMD we would like to do something 
similar, as we have some significant changes to the GPU model we would like to 
push out to the public. We were thinking about doing so with branches, and were 
wondering what others thought about branches? I'm sure it's been discussed 
somewhat in the past, but I can't find much searching through old posts.

What I was thinking would be to have institutional branches, like AMD or ARM 
branches, and perhaps users from those institutions who are also gem5 
maintainers could have user specific branches. We use branches a lot internally 
and find them extremely useful. So I'd like to get a better idea why there is 
an aversion to using branches on the public tree, if there is such an aversion.

-Tony
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] Question about usage of the new vector register file implementation.

[Gutierrez, Anthony]

Hi All,

I am trying to replace our GPU model's vector register implementation with the 
one recently release by ARM: 
https://gem5.googlesource.com/public/gem5/+/0747a432d25ade2c197ca6393270e12606419872,
 and I noticed an issue I didn't catch when I previously reviewed the patch.

From the code, it seems that views of a vector register will break if we try to 
mix VecElem types across views. What I mean is, if we have a vector register 
file where each vector register is 64 lanes of uint32_t, trying to do an 
operation that views a vector register with lanes of uint16_t  will only update 
the first half of the vector register with respect to an operation that views 
the vector register as uint32_t.

Was that the intention? If so, how did you envision people handling operations 
of various sizes on the vector registers (i.e., updating only the lower 16b of 
a 32b lane)? I am thinking I will need to add support for some partial lane 
views, because our GPU instructions can do 16b operations that only update the 
lower bits of a 32b lane, but that has to be done across all lanes.

-Tony
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3800: x86: fix Mul1u instruction

[Gutierrez, Anthony]

I posted the change on Gerrit here: 
https://gem5-review.googlesource.com/c/3400/; feel free to continue the 
discussion there.

It’s been a while since I posted the original patch, so I don’t remember 
precisely which inputs stressed this bug. Basically some precision was lost in 
the upper bits of one of the partial products due to overflow. The computation 
was part of some address calculation that eventually led to a segfault in the 
application under test because the address ends up pointing to some random 
memory.

This patch fixed that issue, as well as Jason’s it seems, among a few other 
issues that mostly manifested as bogus application output (i.e., silent data 
corruption in the app under test’s results).

From: Gabe Black [mailto:gabebl...@google.com]
Sent: Monday, May 15, 2017 2:44 PM
To: Jason Lowe-Power 
Cc: Gross, Joe ; gem5 Developer List ; 
Gutierrez, Anthony 
Subject: Re: [gem5-dev] Review Request 3800: x86: fix Mul1u instruction

Could you give me the specific numbers that are multiplied that don't work?

Gabe

On Mon, May 15, 2017 at 2:42 PM, Jason Lowe-Power 
mailto:ja...@lowepower.com>> wrote:
Something that's really easy to test is printf("%lu\n", (unsigned long)-1); 
This is what I ran into today.

This gives an unmapped memory error because of an incorrect multiply (which is 
how itoa is implemented). This example works with the patch provided.

I think you could come up with many other examples. I think it's the 
upper-order bit calculation that's wrong. So unsigned multiplies near 2^64 give 
wrong answers. Other examples are hard to write since printf causes a crash.

Jason

On Mon, May 15, 2017 at 4:38 PM Gabe Black 
mailto:gabebl...@google.com>> wrote:
I'm a bit suspicious of this new version and how it has fixed width masks and 
extra terms in the addition at the end. Could you please give me an example of 
where the original code got the wrong answer?

Gabe

On Mon, May 15, 2017 at 1:09 PM, Jason Lowe-Power 
mailto:ja...@lowepower.com>> wrote:
We should definitely look into the statetrace tool. I'll put it on my giant 
gem5 list of things to do.

Those of you in industry: There must be some test harnesses for hardware and 
internal simulators. How do you test to make sure instructions are implemented 
correctly?

We've thought about using llvm or gcc tests, but they don't really test what we 
need, IIRC.

Maybe this would be a good summer project for an intern: hint, hint.

Jason

On Mon, May 15, 2017 at 3:04 PM Gross, Joe 
mailto:joseph.gr...@amd.com>> wrote:
Probably we all agree that x86 could use some automated error checking, but I’m 
not sure of any way to do this without a ton of work. CheckerCPU seemed good, 
but as Gabe points out, this may not be comparing against the host hardware.

Jason, do you know any way that’s partially or mostly implemented that we could 
reuse?

Joe

From: Jason Lowe-Power [mailto:ja...@lowepower.com<mailto:ja...@lowepower.com>]
Sent: Monday, May 15, 2017 2:54 PM
To: Gabe Black mailto:gabebl...@google.com>>; gem5 
Developer List mailto:gem5-dev@gem5.org>>
Cc: Gutierrez, Anthony 
mailto:anthony.gutier...@amd.com>>; Gross, Joe 
mailto:joseph.gr...@amd.com>>
Subject: Re: [gem5-dev] Review Request 3800: x86: fix Mul1u instruction

Gabe: Do you want me to wait to push this patch? We can have Tony re-post to 
gerrit if you want to review it. That would be way easier for me anyway.

We need a way to test for these kinds of errors. It's quite upsetting that 
we've had this error in multiply for so long.

Jason

On Mon, May 15, 2017 at 2:50 PM Gabe Black 
mailto:gabebl...@google.com>> wrote:
Please give me a chance to look at it. I think the checker CPU is for 
comparing, say, the O3 CPU against what's effectively the simple CPU. If an 
instruction doesn't do the right thing, it will do the wrong thing no matter 
which CPU is executing it. You can compare against actual execution on a real 
CPU using the statetrace tool, although I saw that somebody rearranged all the 
process startup code which I'd originally carefully matched against actual 
Linux process startup, so that tool probably doesn't give any useful 
information any more.

Gabe

On Mon, May 15, 2017 at 12:45 PM, Joe Gross 
mailto:joseph.gr...@amd.com>> wrote:


> On Feb. 4, 2017, 10:21 a.m., Jason Lowe-Power wrote:
> > Lol, that code is hard to understand. But, LGTM.
> >
> > What are you using to test this? Any chance you can commit the test so we 
> > don't accidentally break this again in the future?
>
> Tony Gutierrez wrote:
> This bug was manifesting in the ROCr runtime while it is loading 
> libraries, it manifested as a segfualt (unmapped addr panic) because an 
> address calculation was corrupted due to this instruction. I manually tested 
> this instruction by comparing its ou

Re: [gem5-dev] Issue with uploaded images on the wiki

[Gutierrez, Anthony]

Thanks, Ali.

-Tony

-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Ali Saidi
Sent: Thursday, April 27, 2017 6:26 AM
To: gem5 Developer List 
Subject: Re: [gem5-dev] Issue with uploaded images on the wiki

It’s been fixed, sorry about that.


Ali

> On Apr 27, 2017, at 8:21 AM, Ali Saidi  wrote:
> 
> I upgraded the wiki about a week ago to address some security issues and 
> something much have gone wrong, I’ll take a look at what is happening.
> 
> Ali
> 
> 
> 
>> On Apr 27, 2017, at 5:53 AM, Andreas Sandberg  
>> wrote:
>> 
>> I had a quick look at the MediaWiki config and it seems like there is 
>> something really weird going on with the server. I have no idea how 
>> this is supposed to be setup, but it seems like there are two 
>> directories for images. Files that can be accessed through the wiki 
>> seem to live in ${HTDOCS}/wiki/images, while the broken ones live in 
>> ${HTDOCS}/wiki/images/images.
>> 
>> Ali, could you have a look? IIRC, you used to handle these sort of 
>> things in the past.
>> 
>> //Andreas
>> 
>> On 25/04/2017 18:22, Gutierrez, Anthony wrote:
>>> Hi gem5 Devs,
>>> 
>>> Has anybody noticed that some of the uploaded images referenced using File 
>>> or Media seem to be missing from the wiki? Maybe it was updated recently?
>>> 
>>> E.g., see this page: http://gem5.org/TraceCPU
>>> 
>>> I noticed this when someone pointed out that our gem5 GPU MICRO 
>>> tutorial slides were missing from here: http://gem5.org/GPU_Models
>>> 
>>> I saw the file was on gem5.org, but the wiki was no longer able to find it. 
>>> I solved this by reuploading the slides and then it just worked, but that 
>>> will be a lot of work to fix all the images.
>>> 
>>> Any mediawiki experts know how to fix this?
>>> 
>>> -Tony
>>> ___
>>> gem5-dev mailing list
>>> gem5-dev@gem5.org
>>> http://m5sim.org/mailman/listinfo/gem5-dev
>> 
>> IMPORTANT NOTICE: The contents of this email and any attachments are 
>> confidential and may also be privileged. If you are not the intended 
>> recipient, please notify the sender immediately and do not disclose the 
>> contents to any other person, use it for any purpose, or store or copy the 
>> information in any medium. Thank you.
>> ___
>> gem5-dev mailing list
>> gem5-dev@gem5.org
>> http://m5sim.org/mailman/listinfo/gem5-dev
> ___
> gem5-dev mailing list
> gem5-dev@gem5.org
> http://m5sim.org/mailman/listinfo/gem5-dev
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] Issue with uploaded images on the wiki

[Gutierrez, Anthony]

Hi gem5 Devs,

Has anybody noticed that some of the uploaded images referenced using File or 
Media seem to be missing from the wiki? Maybe it was updated recently?

E.g., see this page: http://gem5.org/TraceCPU

I noticed this when someone pointed out that our gem5 GPU MICRO tutorial slides 
were missing from here: http://gem5.org/GPU_Models

I saw the file was on gem5.org, but the wiki was no longer able to find it. I 
solved this by reuploading the slides and then it just worked, but that will be 
a lot of work to fix all the images.

Any mediawiki experts know how to fix this?

-Tony
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] scons question

[Gutierrez, Anthony]

There are a three ways to fix this as far as I can tell:

1) Modify our Scons setup to use staged linking.
2) Recompile your kernel to allow for larger ARG_MAX.
3) Modify your paths etc to avoid long names

1) seems to be the best option, but seems like it could be a lot of work.

-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Gabe Black
Sent: Thursday, April 13, 2017 9:50 AM
To: gem5 Developer List 
Subject: Re: [gem5-dev] scons question

Oh, I bet you're right. They actually spawn something like 'sh', '-c', '
'.join(args), and I bet sh (which is symlinked to /bin/bash) is blowing up 
because the command line is very long. I remember my terminal asking if I 
really wanted to copy/paste something like 129K characters when trying to copy 
the command line to run it outside of scons.

Now to figure out how to fix it...

On Thu, Apr 13, 2017 at 8:02 AM, Beckmann, Brad 
wrote:

> Have you investigated the length of the linker command when building 
> from outside the gem5 directory?  In the past, we've seen that 
> mysterious error
> 127 because the linker stage uses a shell command length that exceeds 
> the length supported by the OS.  64KB I believe.  I suspect that the 
> filenames are longer when building outside of gem5, thus it only 
> happens in that situation.  The linker command may be shorter using clang as 
> well.
>
> Brad
>
>
>
> -Original Message-
> From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Gabe 
> Black
> Sent: Thursday, April 13, 2017 1:53 AM
> To: gem5 Developer List 
> Subject: [gem5-dev] scons question
>
> Hi folks. I'm fighting with a very confusing problem with scons at the 
> moment. For reasons I haven't determined, when I have things set up to 
> build when scons is run from outside the gem5 directory (using -C), it 
> fails the final linker step with error 127 and no other output 100% of 
> the time. If I run from within the gem5 directory everything works fine.
>
> I did some reading, and bash reports error 127 when it can't find the 
> command you asked it to run. To determine if that might be the 
> problem, I modified scons to run "which" on each command it was about 
> to spawn before it did, to make sure it resolved to something. That 
> worked just fine. If I run the command manually, it returns exit code 
> 0. If I take the environment scons tries to run g++ under and 
> partially duplicate that with a script and env -i, it still succeeds.
>
> If I run with clang instead of g++, I get the same behavior which 
> makes me think it's not g++ doing something weird, it's scons. I can't 
> for the life of me figure out what though, and I can't seem to get any 
> information to work with other than this mysterious error 127.
>
> If any of you have any idea why it's doing what it's doing, or if 
> there's any information I can gather that might help, I would be very 
> happy to hear it.
>
> Gabe
> ___
> gem5-dev mailing list
> gem5-dev@gem5.org
> http://m5sim.org/mailman/listinfo/gem5-dev
> ___
> gem5-dev mailing list
> gem5-dev@gem5.org
> http://m5sim.org/mailman/listinfo/gem5-dev
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Best method for adding code to ext/

[Gutierrez, Anthony]

As an aside, I would prefer to avoid sub repos if at all possible. I am not 
sure how sub-repos work in Git, but if it is anything like HG they are a pain 
IMO.

-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Gutierrez, 
Anthony
Sent: Friday, March 03, 2017 2:57 PM
To: gem5 Developer List 
Subject: Re: [gem5-dev] Best method for adding code to ext/

Another possibility is that we could use the Git Repo tool from Google. If any 
of these external libs have corresponding Git repos out there somewhere, it 
could automatically pull those (even at specific revs if need be), or we could 
mirror them in separate Git repos on googlesource.

-Tony

-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Jason Lowe-Power
Sent: Friday, March 03, 2017 11:36 AM
To: gem5 Developer List 
Subject: [gem5-dev] Best method for adding code to ext/

Hi all,

There are a couple of patches in review that add a large chunk of code from 
other repositories to gem5 in ext/. Andreas S. has a patch that adds
PyBind11 and Matthias is updating DRAMPower. And we're thinking about including 
SystemC in a similar way.

Is there a better way for us to include these other projects in gem5's source 
tree? For instance, we could use subrepos. What is the community's thoughts on 
this?

A few things I don't like about including the code in gem5:
1) It increases the amount of code in our repository
2) It is hard to track updates to these systems
3) The code cannot be GPL.

Good thing about including the code in gem5:
1) Updates to external code won't break our system
2) It's easy to build gem5 without having to download other software

Any other opinions or options for this?

Thanks,
Jason
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Best method for adding code to ext/

[Gutierrez, Anthony]

Another possibility is that we could use the Git Repo tool from Google. If any 
of these external libs have corresponding Git repos out there somewhere, it 
could automatically pull those (even at specific revs if need be), or we could 
mirror them in separate Git repos on googlesource.

-Tony

-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Jason Lowe-Power
Sent: Friday, March 03, 2017 11:36 AM
To: gem5 Developer List 
Subject: [gem5-dev] Best method for adding code to ext/

Hi all,

There are a couple of patches in review that add a large chunk of code from 
other repositories to gem5 in ext/. Andreas S. has a patch that adds
PyBind11 and Matthias is updating DRAMPower. And we're thinking about including 
SystemC in a similar way.

Is there a better way for us to include these other projects in gem5's source 
tree? For instance, we could use subrepos. What is the community's thoughts on 
this?

A few things I don't like about including the code in gem5:
1) It increases the amount of code in our repository
2) It is hard to track updates to these systems
3) The code cannot be GPL.

Good thing about including the code in gem5:
1) Updates to external code won't break our system
2) It's easy to build gem5 without having to download other software

Any other opinions or options for this?

Thanks,
Jason
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Ideas for sprint projects

[Gutierrez, Anthony]

Here are some ideas we at AMD have for the sprint.

1) Adding checkpointing support to the GPU model
2) Fixing the structure and design of the GPU coalescer
3) Adding x86 inst tests
4) Properly supporting atomics
5) Add support for event-based scheduling in the GPU model, and FUPool-style 
functional units

-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Jason Lowe-Power
Sent: Tuesday, January 17, 2017 8:13 AM
To: gem5 Developer List 
Subject: [gem5-dev] Ideas for sprint projects

Hi gem5 Developers!

As you're probably aware, I'm going to be running a gem5 coding sprint in the 
afternoon after the Learning gem5 tutorial at HPCA on Sunday Feb 5.

I'm looking for ideas for small projects that could be started (or even better, 
completed) in a few hours. Do you have any small bugs that have been bothering 
you? Any little features that would be nice, but you haven't had the time to 
work on? Now's the time to get these things done!

Also, if you have any bigger projects that you think it would be good for 
people to chat about in the same room to come up with a plan of attack, we may 
be able to fit one or two of those in, too.

Some examples that I have so far:

Little projects:
1. Fix TLB warmup for x86. (See http://reviews.gem5.org/r/3474/) 2. Modify 
EventWrapper to understand C++11 lambdas so you can pass parameters to simple 
process() functions without creating a new class.
3. Develop some ISA instruction tests to find out what is implemented correctly 
and possibly find some bugs. (See RISC-V insttest)

Long-term things we may want to discuss:
1. Revamping the test infrastructure
2. Replacing scons, possibly with Bazel (see https://bazel.build/)

Please respond with any ideas you have! We definitely won't get to everything, 
but throwing ideas out there now will give us a large base of options for the 
coding sprint.

Thanks,
Jason
-- 

Jason
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] changeset in gem5: syscall_emul: add support for x86 statfs syst...

[Gutierrez, Anthony]

We do not have access to BSD or OSX, so unless somebody can give Brandon access 
to such a machine he would have no way to test any potential fix.

From a high level, the only easy solution I see is to guard OS-specific code 
with #ifdefs or something similar. It seems that if we are going to support 
more advanced OS features and syscalls in SE mode a fundamental refactoring of 
SE code may be necessary, and will require help from everybody. Brandon has 
already done a lot down this path, adding support for dynamic linking, 
pthreads, and has done a lot of refactoring here.

Could somebody who is more familiar with BSD, and has access, try to come up 
with a fix? Brandon is merely adding a feature here, and the fact that it 
breaks support for some other feature is an artifact of the simulator design, 
and I don't want to put the onus on individual contributors to fix fundamental 
flaws when adding useful features. Hopefully we can come up with a solution as 
a community.

-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Andreas Hansson
Sent: Thursday, January 12, 2017 12:45 AM
To: gem5 Developer List ; Potter, Brandon 

Cc: gem5-...@m5sim.org
Subject: Re: [gem5-dev] changeset in gem5: syscall_emul: add support for x86 
statfs syst...

Hi Brandon,

Could you have a look at this and come up with some form of solution so that 
gem5 compiles on BSD and OSX as well?

Thanks,

Andreas

On 22/12/2016, 10:30, "gem5-dev on behalf of Bjoern A. Zeeb"

wrote:

>On 15 Dec 2016, at 18:17, Brandon Potter wrote:
>
>> changeset deaf82fd2e7c in /z/repo/gem5
>> details: http://repo.gem5.org/gem5?cmd=changeset;node=deaf82fd2e7c
>> description:
>> syscall_emul: add support for x86 statfs system calls
>>
>
>Does this compile on anything but Linux?   statfs.h doesn’t exists
>elsewhere I guess?   statfs is historic and still more or less OS
>specific.
>
>Did you actually implement statfs, or is this statvfs as in 
>http://pubs.opengroup.org/onlinepubs/95399/basedefs/sys/statvfs.h.h
>tml
>
>?   Not sure what the linux syscall does there?
>
>
>
>> diffstat:
>>
>>  src/arch/x86/linux/linux.hh   |  18 ++
>>  src/arch/x86/linux/process.cc |   2 +-
>>  src/sim/syscall_emul.hh   |  32 ++--
>>  3 files changed, 49 insertions(+), 3 deletions(-)
>>
>> diffs (110 lines):
>>
>> diff -r 104a404d426e -r deaf82fd2e7c src/arch/x86/linux/linux.hh
>> --- a/src/arch/x86/linux/linux.hhThu Dec 15 13:14:41 2016 -0500
>> +++ b/src/arch/x86/linux/linux.hhThu Dec 15 13:16:03 2016 -0500
>> @@ -67,6 +67,24 @@
>>  int64_t unused0[3];
>>  } tgt_stat64;
>>
>> +typedef struct {
>> +long val[2];
>> +} tgt_fsid;
>> +
>> +typedef struct {
>> +long f_type;
>> +long f_bsize;
>> +long f_blocks;
>> +long f_bfree;
>> +long f_bavail;
>> +long f_files;
>> +long f_ffree;
>> +tgt_fsid f_fsid;
>> +long f_namelen;
>> +long f_frsize;
>> +long f_spare[5];
>> +} tgt_statfs;
>> +
>>  static const int TGT_SIGHUP = 0x01;
>>  static const int TGT_SIGINT = 0x02;
>>  static const int TGT_SIGQUIT= 0x03;
>> diff -r 104a404d426e -r deaf82fd2e7c src/arch/x86/linux/process.cc
>> --- a/src/arch/x86/linux/process.ccThu Dec 15 13:14:41 2016 -0500
>> +++ b/src/arch/x86/linux/process.ccThu Dec 15 13:16:03 2016 -0500
>> @@ -355,7 +355,7 @@
>>  /* 134 */ SyscallDesc("uselib", unimplementedFunc),
>>  /* 135 */ SyscallDesc("personality", unimplementedFunc),
>>  /* 136 */ SyscallDesc("ustat", unimplementedFunc),
>> -/* 137 */ SyscallDesc("statfs", unimplementedFunc),
>> +/* 137 */ SyscallDesc("statfs", statfsFunc),
>>  /* 138 */ SyscallDesc("fstatfs", unimplementedFunc),
>>  /* 139 */ SyscallDesc("sysfs", unimplementedFunc),
>>  /* 140 */ SyscallDesc("getpriority", unimplementedFunc), diff -r 
>> 104a404d426e -r deaf82fd2e7c src/sim/syscall_emul.hh
>> --- a/src/sim/syscall_emul.hhThu Dec 15 13:14:41 2016 -0500
>> +++ b/src/sim/syscall_emul.hhThu Dec 15 13:16:03 2016 -0500
>> @@ -62,6 +62,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -451,6 +452,7 @@
>>  //
>>  
>> /
>> /
>>
>> +typedef struct statfs hst_statfs;
>>  #if NO_STAT64
>>  typedef struct stat hst_stat;
>>  typedef struct stat hst_stat64;
>> @@ -556,6 +558,32 @@
>>  tgt.copyOut(mem);
>>  }
>>
>> +template 
>> +static void
>> +copyOutStatfsBuf(SETranslatingPortProxy &mem, Addr addr,
>> + hst_statfs *host)
>> +{
>> +TypedBufferArg tgt(addr);
>> +
>> +#if defined(__OpenBSD__) || defined(__APPLE__) ||
>> defined(__FreeBSD__)
>> +tgt->f_type = 0;
>> +#else
>> +tgt->f_type = TheISA::htog(host->f_type); #endif
>> +tgt->f_bsize = TheISA::htog(host->f_bsize);
>> +tgt->f_bloc

Re: [gem5-dev] Status of RISC-V patches

[Gutierrez, Anthony]

Hi Andreas,

I agree with this sentiment overall as I think our collection of regressions 
currently are pretty ad-hoc; they are basically just the benchmarks that people 
want to ensure run for their in gem5, i.e, SPEC etc. I think smaller LLVM unit 
tests would provide more directed testing, similar or better coverage, less 
maintenance, and a suitable license.

Just to clarify when you say 'LLVM-specific' tests, are you referring to the 
unit/regression tests: http://llvm.org/docs/TestingGuide.html#regression-tests 
? We are also thinking of using similar HCC tests (AMD's LLVM-based compiler 
for heterogeneous accelerators): 
https://github.com/RadeonOpenCompute/hcc/tree/clang_tot_upgrade/tests/Unit for 
our GPU model in gem5.

For testing, I'm assuming we're going to want something like Jenkins going 
forward. The question is where will such a server live, and will it be 
accessible to the public?

-Tony

-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Andreas Hansson
Sent: Monday, November 14, 2016 2:40 PM
To: gem5 Developer List ; Jason Lowe-Power 

Subject: Re: [gem5-dev] Status of RISC-V patches

Hi all,

Merely a thought when it comes to adding tests:

I would suggest we ditch all proprietary/closed-source tests and move in the 
direction of something that is open and maintained. My proposal would be to 
adopt a few of the tests from the llvm test suite. There are both very short 
LLVM-specific tests that are BSD licensed, and a bunch of smaller “apps” that 
maintain their original license. It would be great if we could identify a few 
relevant tests from the tests suite and start going in that direction. The 
source for the tests along with build scripts etc should probably be in a repo 
on their own.

What do you think?

Andreas

On 28/10/2016, 22:12, "gem5-dev on behalf of Alec Roelke"
 wrote:

>I think I get it.  Thanks for your help!
>
>It looks like I won't be able to make use of any tests other than 
>00.hello, because either they're multithreaded or pieces of them are 
>missing.  I'm going to try to put my instruction tests into 
>02.insttest.
>
>On Fri, Oct 28, 2016 at 11:01 AM, Jason Lowe-Power 
>
>wrote:
>
>> Hi Alec,
>>
>> Our regression testing infrastructure is confusing, to say the least.
>> Honestly, it would take me at least a few hours to figure out how to 
>>add  new regressions again. But here's a little information that 
>>hopefully will  help you save some time.
>>
>> You need to put reference outputs in tests/quick/se/> NAME>/ref/riscv/linux/.
>>
>> The config files are in tests/configs. One of these files (without 
>>the
>> .py) is what goes in  above. The  can be  
>>anything. Using some of the same tests that are there make sense, but 
>>you  may want to add other RISC-V specific tests as well.
>>
>> You *may* be able to use the config files in tests/configs without  
>>changes, but maybe not. I'm not sure. You'll probably be able to use 
>>some  but not others.
>>
>> Getting scons to run your regressions is totally black magic to me.
>>Here's
>> a couple of things I've learned, though.
>> 1) You should delete the build directory (e.g., build/RISCV/tests/
>> debug/quick/se/00.hello/riscv/) every time you want to re-run the  
>>regression.
>> 2) The regression won't even try to run if you don't have dummy files 
>>in  tests/quick/se//ref/riscv/linux/.
>>
>> For the missing stats/changed stats, since this is first time you're  
>>running the RISC-V stats, I would totally ignore all of that 
>>information. I  would just look at the output (simout/simerr) and make 
>>sure it seems  reasonable (e.g., no errors). If you have an idea of a 
>>stat that you expect  to see (e.g., floating point ops > 0) then you 
>>could look at the stats file  too to make sure it's what you expect.
>>
>> There's no specific configuration you should be using. For the most 
>>part,  all of the tests are just functional tests. The configurations 
>>for the  system are specified in the tests/configs (>NAME>) Python files.
>>
>> Hopefully this will help you get started. Let us know if you have 
>> more questions. Maybe someone with more regression tester experience 
>> will be able to help more.
>>
>> Jason
>>
>> On Thu, Oct 27, 2016 at 8:23 PM Alec Roelke  wrote:
>>
>>> I'll start with converting as many from "quick" as I can.  If/when I 
>>>end  up creating my own, is there a convention for what they should 
>>>be named and  where they should go?
>>>
>>> Also, I'm having a bit of a problem with just 00.hello.  I compiled 
>>>the  source in tests/test-progs/hello/src into 
>>>tests/test-progs/hello/bin/riscv/linux
>>> (for some reason mine disappeared), and then created  
>>>tests/quick/se/00.hello/ref/riscv/linux/simple-atomic.  Then I 
>>>compiled  and ran build/RISCV/gem5.fast, configuring for the atomic 
>>>CPU and  redirecting the output stats, configuration, stdout, and 
>>>stderr into that  directory.  But when I run 
>>>build/RISCV/tests/debug/quick/  

Re: [gem5-dev] macro (and identifier) problems in our source code

[Gutierrez, Anthony]

Yes, I agree the _name designations are meant for clashes between private 
members and their accessors. I would also prefer that members still use camel 
case, and I'm not a fan of m_ to designate members. We could think about 
prepending get/set in front of accessors, but I doubt that will be popular 
either.

As far as include guards go, your suggestion is fine, although I think any 
conflicts are currently due to incorrectly formatted include guards. I believe 
the correct format is supposed to be like:

__PATH_IN_GEM5_SRC_TREE_FILE_NAME_HH__

But a lot of people seem to leave off the path name.

As far as the macros go, I am not crazy about adding 5 characters either  
(GEM5_). That said I think we should probably not be using macros for many 
things we currently use them for; i.e., we should be using inlines, constexpr, 
and consts. So if we could restrict our usage of macros to the few cases they 
are needed, then I think requiring GEM5_ for macros would be ok.

-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Potter, Brandon
Sent: Monday, October 10, 2016 3:02 PM
To: gem5 Developer List 
Subject: Re: [gem5-dev] macro (and identifier) problems in our source code

Hi Andreas,

I thought that the _name designations were meant for private members with 
accessors; that's what the style guide says: "Class members that have accessor 
methods should have a leading underscore to indicate that the user should be 
using an accessor. The accessor functions themselves should have the same name 
as the variable without the leading underscore." It's not always an issue with 
the members being named with an underscore, but I have seen cases with acronyms 
as the first few characters with full capitalization... so an error according 
to the C++ standard.

The macros in "src/base/misc.hh" that are used extensively are named panic, 
warn, and fatal. These are examples which are particularly likely to cause 
conflicts (as I found out this past weekend). The problem manifested as an 
error after a macro called another macro caused by a conflict on a function 
name. So, preprocessor sees the "warn" define from "misc.hh" and then sees 
"warn" from . It has already seen the macro so it decides to start 
replacing the declaration in the  header file.  Since the "warn" macro 
from "misc.hh" called another macro it was tough to track the problem down; the 
compiler pointed me to the nested macro and I stared at that code and the 
surrounding code for a while before realizing the problem with . Also, 
the header that included "misc.hh" was nested in the header file a few includes 
away.  Frankly, it was a waste of time that other developers probably would 
like to avoid going forward. I'm suggesting added the extra characters so that 
no one else runs into the problem again (at least as long as we don't include 
header files from the OTHER gem5 project). I know that it will offset the code 
and likely cause some line issues that need to be resolved, but it seems like a 
better programming practice to adopt rather than maintain the status quo and 
continue to add code.  I do agree that it's unfortunate though to need the 
extra characters However, imagine how nice it would be now if it had been 
adopted earlier in development.  You'd be able to look at a macro and know that 
it's a macro without needing to resort to header files to verify; also, you'd 
know that it was unique and need not worry about collisions.

Regards,
Brandon

-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Andreas Hansson
Sent: Monday, October 10, 2016 4:14 PM
To: gem5 Developer List 
Subject: Re: [gem5-dev] macro (and identifier) problems in our source code

Hi Brandon,

No objection on the header include guards.

When it comes to private members, I would suggest to just stick with nameOfVar. 
We have only used _name when there is a constructor parameter name, and it is 
actually not necessary. It is fine to have the private member be just name, and 
let the constructor parameter name initialise it with name(name).

What macros are causing problems? Adding 5 characters to each and everyone 
seems rather unfortunate.

Andreas

On 10/10/2016, 18:52, "gem5-dev on behalf of Potter, Brandon"
 wrote:

>Hello all,
>
>I just posted a patch, http://reviews.gem5.org/r/3650/, which deals 
>with a name collision between a macro that's defined in our source and 
>a function declaration included from a standard header. Seems like a 
>rare collision that I stumbled into, but we should do a better job of 
>naming our macros given that collisions are a possibility. With macros, 
>we can't use namespaces to prevent this from happening, but we could 
>make a rule where we append something like "_GEM5" onto all of the 
>macros. (It is a much larger problem than function names which is what 
>the issue is on
>RB.) Does anyone have thoughts on this suggestion? If it's a good 
>suggestion, does a

Re: [gem5-dev] FW: [gem5-users] scons build error for Garnet 2.0

[Gutierrez, Anthony]

Agreed. I certainly prefer to simply remove it, and I think I speak for most 
folks at AMD (although I'd need to double check), but I'm not going to force 
the issue if others still use it and would like to keep it around.

-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Andreas Hansson
Sent: Monday, October 17, 2016 1:31 PM
To: gem5 Developer List 
Subject: Re: [gem5-dev] FW: [gem5-users] scons build error for Garnet 2.0

Hi all,

Why not grab the opportunity? Jason, what is the reason for the weeks/months? 
Why couldn’t we remove Alpha this week if we decide that’s the right thing to 
do?

Andreas

On 17/10/2016, 16:37, "gem5-dev on behalf of Gutierrez, Anthony"
 wrote:

>I would like to see this clarified before we ask Brandon to go work on 
>fixing ALPHA. If it is going to be phased out in a matter of months, I 
>don't think we should be asking him to waste his time on fixing it.
>
>-Original Message-
>From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Jason 
>Lowe-Power
>Sent: Monday, October 17, 2016 7:34 AM
>To: gem5 Developer List 
>Subject: Re: [gem5-dev] FW: [gem5-users] scons build error for Garnet 
>2.0
>
>Hi Brandon,
>
>We've had this discussion before. See this thread:
>http://www.mail-archive.com/gem5-dev@gem5.org/msg19380.html
>
>In summary... I think we're planning on phasing out ALPHA, but that 
>won't happen in the very short term (weeks), but may happen in the 
>medium term (months).
>
>Cheers,
>Jason
>
>On Mon, Oct 17, 2016 at 9:28 AM Potter, Brandon 
>
>wrote:
>
>> Switching this over to the dev mailing list since it seems more  
>>suitable (and I don’t have a user account; need to rectify that at 
>>some point).
>>
>> -Brandon
>>
>> From: Potter, Brandon
>> Sent: Monday, October 17, 2016 9:25 AM
>> To: 'Andreas Hansson' ; gem5 users mailing 
>> list < gem5-us...@gem5.org>
>> Subject: RE: [gem5-users] scons build error for Garnet 2.0
>>
>> Yes, I can fix it, but it’s difficult to know what values are for Tru64.
>>
>> Can we deprecate Alpha already?  It looks like the last commercial 
>> product that came out with Alpha was in 2007, almost a decade ago. I 
>> don’t think that I know anyone personally who uses a 10 year old 
>> computer.  I don’t think that I’ve ever used an Alpha either to boot; 
>> wondering why I need to go out of my way to try to support it.
>>
>> Does anyone use Alpha outside of running our regressions?
>>
>> -Brandon
>>
>> From: Andreas Hansson [mailto:andreas.hans...@arm.com]
>> Sent: Monday, October 17, 2016 3:29 AM
>> To: gem5 users mailing list > gem5-us...@gem5.org>>
>> Cc: Potter, Brandon
>> mailto:brandon.pot...@amd.com
>> >>
>> Subject: Re: [gem5-users] scons build error for Garnet 2.0
>>
>> My bad, this is properly broken for ALPHA and tru64.
>>
>> In fact this was broken as part of:
>>
>> changeset:   11383:5ac090acd180
>> user:Brandon Potter > brandon.pot...@amd.com>>
>> date:Thu Mar 17 10:24:17 2016 -0700
>> summary: syscall_emul: extend mmap system call to support file
>>backed
>> mmap
>>
>> It was later fixed for Linux, but not tru64 it appears.
>>
>> Brandon, could you get this resolved?
>>
>> Thanks,
>>
>> Andreas
>>
>> From: gem5-users > gem5-users-boun...@gem5.org>> on behalf of Andreas Hansson < 
>> andreas.hans...@arm.com<mailto:andreas.hans...@arm.com>>
>> Reply-To: gem5 users mailing list > gem5-us...@gem5.org>>
>> Date: Monday, 17 October 2016 at 08:54
>> To: gem5 users mailing list > gem5-us...@gem5.org>>
>> Subject: Re: [gem5-users] scons build error for Garnet 2.0
>>
>> Just use clang (i.e. the default OSX compiler).
>>
>> Andreas
>>
>> From: gem5-users > gem5-users-boun...@gem5.org>> on behalf of "F. A. Faisal" < 
>> dipu.7...@gmail.com<mailto:dipu.7...@gmail.com>>
>> Reply-To: gem5 users mailing list > gem5-us...@gem5.org>>
>> Date: Saturday, 15 October 2016 at 14:22
>> To: gem5 users mailing list > gem5-us...@gem5.org>>
>> Subject: Re: [gem5-users] scons build error for Garnet 2.0
>>
>>
>> I tried with another gcc, but the result is the same...
>>
>>
>>
>> $ port select --set gccmp-gcc49
>>
>>
>>
>> $ port select --list gcc
>>
>> Warning: port definitions are more than two weeks old, consider 
>> upd

Re: [gem5-dev] FW: [gem5-users] scons build error for Garnet 2.0

[Gutierrez, Anthony]

I would like to see this clarified before we ask Brandon to go work on fixing 
ALPHA. If it is going to be phased out in a matter of months, I don't think we 
should be asking him to waste his time on fixing it.

-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Jason Lowe-Power
Sent: Monday, October 17, 2016 7:34 AM
To: gem5 Developer List 
Subject: Re: [gem5-dev] FW: [gem5-users] scons build error for Garnet 2.0

Hi Brandon,

We've had this discussion before. See this thread:
http://www.mail-archive.com/gem5-dev@gem5.org/msg19380.html

In summary... I think we're planning on phasing out ALPHA, but that won't 
happen in the very short term (weeks), but may happen in the medium term 
(months).

Cheers,
Jason

On Mon, Oct 17, 2016 at 9:28 AM Potter, Brandon 
wrote:

> Switching this over to the dev mailing list since it seems more 
> suitable (and I don’t have a user account; need to rectify that at some 
> point).
>
> -Brandon
>
> From: Potter, Brandon
> Sent: Monday, October 17, 2016 9:25 AM
> To: 'Andreas Hansson' ; gem5 users mailing 
> list < gem5-us...@gem5.org>
> Subject: RE: [gem5-users] scons build error for Garnet 2.0
>
> Yes, I can fix it, but it’s difficult to know what values are for Tru64.
>
> Can we deprecate Alpha already?  It looks like the last commercial 
> product that came out with Alpha was in 2007, almost a decade ago. I 
> don’t think that I know anyone personally who uses a 10 year old 
> computer.  I don’t think that I’ve ever used an Alpha either to boot; 
> wondering why I need to go out of my way to try to support it.
>
> Does anyone use Alpha outside of running our regressions?
>
> -Brandon
>
> From: Andreas Hansson [mailto:andreas.hans...@arm.com]
> Sent: Monday, October 17, 2016 3:29 AM
> To: gem5 users mailing list  gem5-us...@gem5.org>>
> Cc: Potter, Brandon 
> mailto:brandon.pot...@amd.com
> >>
> Subject: Re: [gem5-users] scons build error for Garnet 2.0
>
> My bad, this is properly broken for ALPHA and tru64.
>
> In fact this was broken as part of:
>
> changeset:   11383:5ac090acd180
> user:Brandon Potter  brandon.pot...@amd.com>>
> date:Thu Mar 17 10:24:17 2016 -0700
> summary: syscall_emul: extend mmap system call to support file backed
> mmap
>
> It was later fixed for Linux, but not tru64 it appears.
>
> Brandon, could you get this resolved?
>
> Thanks,
>
> Andreas
>
> From: gem5-users  gem5-users-boun...@gem5.org>> on behalf of Andreas Hansson < 
> andreas.hans...@arm.com>
> Reply-To: gem5 users mailing list  gem5-us...@gem5.org>>
> Date: Monday, 17 October 2016 at 08:54
> To: gem5 users mailing list  gem5-us...@gem5.org>>
> Subject: Re: [gem5-users] scons build error for Garnet 2.0
>
> Just use clang (i.e. the default OSX compiler).
>
> Andreas
>
> From: gem5-users  gem5-users-boun...@gem5.org>> on behalf of "F. A. Faisal" < 
> dipu.7...@gmail.com>
> Reply-To: gem5 users mailing list  gem5-us...@gem5.org>>
> Date: Saturday, 15 October 2016 at 14:22
> To: gem5 users mailing list  gem5-us...@gem5.org>>
> Subject: Re: [gem5-users] scons build error for Garnet 2.0
>
>
> I tried with another gcc, but the result is the same...
>
>
>
> $ port select --set gccmp-gcc49
>
>
>
> $ port select --list gcc
>
> Warning: port definitions are more than two weeks old, consider 
> updating them by running 'port selfupdate'.
>
> Available versions for gcc:
>
> apple-gcc42
>
> mp-gcc47
>
> mp-gcc49 (active)
>
> none
>
>
>
> $ scons build/ALPHA_MOESI_hammer/gem5.debug
>
> build/ALPHA_MOESI_hammer/arch/alpha/tru64/tru64.cc:82:21: error:
> 'MAP_LOCKED' was not declared in this scope
>
>{ TGT_MAP_LOCKED, MAP_LOCKED },
>
>  ^
>
> build/ALPHA_MOESI_hammer/arch/alpha/tru64/tru64.cc:83:23: error:
> 'MAP_NONBLOCK' was not declared in this scope
>
>{ TGT_MAP_NONBLOCK, MAP_NONBLOCK },
>
>^
>
> build/ALPHA_MOESI_hammer/arch/alpha/tru64/tru64.cc:85:23: error:
> 'MAP_POPULATE' was not declared in this scope
>
>{ TGT_MAP_POPULATE, MAP_POPULATE },
>
>^
>
> build/ALPHA_MOESI_hammer/arch/alpha/tru64/tru64.cc:86:20: error:
> 'MAP_STACK' was not declared in this scope
>
>{ TGT_MAP_STACK, MAP_STACK },
>
> ^
>
> scons: *** [build/ALPHA_MOESI_hammer/arch/alpha/tru64/tru64.do] Error 
> 1
>
> scons: building terminated because of errors.
>
>
>
> Thanks...
>
>
> On Sat, Oct 15, 2016 at 10:06 PM, Abdul Mutaal  > wrote:
>
> Try with >=4.5
>
> On Oct 15, 2016 2:56 PM, "F. A. Faisal"  dipu.7...@gmail.com>> wrote:
>
> $ g++ -v
>
> Configured with: 
> --prefix=/Applications/Xcode.app/Contents/Developer/usr
> --with-gxx-include-dir=/usr/include/c++/4.2.1
>
> Apple LLVM version 7.3.0 (clang-703.0.29)
>
> Target: x86_64-apple-darwin15.4.0
>
> Thread model: posix
>
> On Sat, Oct 15, 2016 at 9:53 PM, Abdul Mutaal  > wrote:
> C++ version ?
>
>

Re: [gem5-dev] Review Request 3647: ruby: Fix broken regressions

[Gutierrez, Anthony]

Thanks, Tushar.

-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Krishna, Tushar
Sent: Friday, October 07, 2016 4:01 PM
To: gem5 Developer List 
Subject: Re: [gem5-dev] Review Request 3647: ruby: Fix broken regressions

Thanks.
I see the error too now. 
It looks like the CPU-GPU system creates the topology in a somewhat different 
manner than the pure CPU protocols that I am familiar with (and tested all my 
changes with).
Let me dig deeper into it and then send out a patch.

Thanks,
Tushar


> On Oct 7, 2016, at 6:37 PM, Gutierrez, Anthony  
> wrote:
> 
> You can reproduce the error if you run apu_se.py by hand. For example:
> 
> # build the HSAIL GPU
> scons -jN ./build/HSAIL_X86/gem5.opt
> 
> # run the GPU hello test
> ./build/HSAIL_X86/gem5.opt configs/example/apu_se.py -c 
> tests/test-progs/gpu-hello/bin/x86/linux/gpu-hello -k 
> tests/test-progs/gpu-hello/bin/x86/linux/gpu-hello-kernel.asm
> 
> -Original Message-
> From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of 
> Krishna, Tushar
> Sent: Friday, October 07, 2016 3:26 PM
> To: gem5 Developer List 
> Subject: Re: [gem5-dev] Review Request 3647: ruby: Fix broken 
> regressions
> 
> Hi Brandon,
> SimpleIntLink inherits from BasicIntLink (which defines dst_node) so this 
> error shouldn’t ideally show up. I don’t see it when I run the simple network.
> Can you tell me what command you ran?
> I’ll try reproducing and debugging it on my end.
> 
> Cheers,
> Tushar
> 
> 
>> On Oct 7, 2016, at 6:15 PM, Andreas Hansson  wrote:
>> 
>> 
>> 
>>> On Oct. 7, 2016, 10:04 p.m., Brandon Potter wrote:
>>>> I'm noticing that this patch doesn't completely fix the regressions on its 
>>>> own. There are still two failures that I'm seeing with it applied 
>>>> (although they may be unrelated, not sure):
>>>> 
>>>> `cat
>>>> build/HSAIL_X86/tests/opt/quick/se/04.gpu/x86/linux/gpu-ruby-GPU_Rf
>>>> O
>>>> /simerr`
>>>> 
>>>> warn: add_child('dst_node_'): child 'int_node' already has parent
>>>> warn: add_child('dst_node_'): child 'int_node' already has parent
>>>> warn: add_child('dst_node_'): child 'int_node' already has parent
>>>> warn: add_child('dst_node_'): child 'dst_node_' already has parent 
>>>> Traceback (most recent call last):
>>>> File "", line 1, in   File 
>>>> "/home/bpotter/Research/gem5/gem5-public-process/src/python/m5/main.py", 
>>>> line 400, in main
>>>>   exec filecode in scope
>>>> File 
>>>> "/home/bpotter/Research/gem5/gem5-public-process/tests/testing/../run.py", 
>>>> line 184, in 
>>>>   execfile(joinpath(tests_root, 'configs', test_filename + '.py')) 
>>>> File 
>>>> "/home/bpotter/Research/gem5/gem5-public-process/tests/testing/../configs/gpu-ruby.py",
>>>>  line 282, in 
>>>>   Ruby.create_system(options, None, system)  File 
>>>> "/home/bpotter/Research/gem5/gem5-public-process/configs/ruby/Ruby.py", 
>>>> line 175, in create_system
>>>>   Network.init_network(options, network, InterfaceClass)  File 
>>>> "/home/bpotter/Research/gem5/gem5-public-process/configs/network/Network.py",
>>>>  line 108, in init_network
>>>>   network.setup_buffers()
>>>> File 
>>>> "/home/bpotter/Research/gem5/gem5-public-process/src/mem/ruby/network/simple/SimpleNetwork.py",
>>>>  line 62, in setup_buffers
>>>>   if link.dst_node == router:
>>>> File 
>>>> "/home/bpotter/Research/gem5/gem5-public-process/src/python/m5/SimObject.py",
>>>>  line 1105, in __getattr__
>>>>   raise AttributeError, err_string
>>>> AttributeError: object 'SimpleIntLink' has no attribute 'dst_node'
>>>> (C++ object is not yet constructed, so wrapped C++ methods are
>>>> unavailable.)
>>>> 
>>>> `cat
>>>> build/HSAIL_X86/tests/opt/quick/se/60.gpu-randomtest/x86/linux/gpu-
>>>> r
>>>> andomtest-ruby-GPU_RfO/simerr`
>>>> 
>>>> warn: add_child('dst_node_'): child 'int_node' already has parent
>>>> warn: add_child('dst_node_'): child 'int_node' already has parent
>>>> warn: add_child('dst_node_'): child 'int_node' alr

Re: [gem5-dev] Review Request 3647: ruby: Fix broken regressions

[Gutierrez, Anthony]

You can reproduce the error if you run apu_se.py by hand. For example:

# build the HSAIL GPU
scons -jN ./build/HSAIL_X86/gem5.opt

# run the GPU hello test
./build/HSAIL_X86/gem5.opt configs/example/apu_se.py -c 
tests/test-progs/gpu-hello/bin/x86/linux/gpu-hello -k 
tests/test-progs/gpu-hello/bin/x86/linux/gpu-hello-kernel.asm

-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Krishna, Tushar
Sent: Friday, October 07, 2016 3:26 PM
To: gem5 Developer List 
Subject: Re: [gem5-dev] Review Request 3647: ruby: Fix broken regressions

Hi Brandon,
SimpleIntLink inherits from BasicIntLink (which defines dst_node) so this error 
shouldn’t ideally show up. I don’t see it when I run the simple network.
Can you tell me what command you ran?
I’ll try reproducing and debugging it on my end.

Cheers,
Tushar


> On Oct 7, 2016, at 6:15 PM, Andreas Hansson  wrote:
> 
> 
> 
>> On Oct. 7, 2016, 10:04 p.m., Brandon Potter wrote:
>>> I'm noticing that this patch doesn't completely fix the regressions on its 
>>> own. There are still two failures that I'm seeing with it applied (although 
>>> they may be unrelated, not sure):
>>> 
>>> `cat 
>>> build/HSAIL_X86/tests/opt/quick/se/04.gpu/x86/linux/gpu-ruby-GPU_RfO
>>> /simerr`
>>> 
>>> warn: add_child('dst_node_'): child 'int_node' already has parent
>>> warn: add_child('dst_node_'): child 'int_node' already has parent
>>> warn: add_child('dst_node_'): child 'int_node' already has parent
>>> warn: add_child('dst_node_'): child 'dst_node_' already has parent 
>>> Traceback (most recent call last):
>>>  File "", line 1, in   File 
>>> "/home/bpotter/Research/gem5/gem5-public-process/src/python/m5/main.py", 
>>> line 400, in main
>>>exec filecode in scope
>>>  File 
>>> "/home/bpotter/Research/gem5/gem5-public-process/tests/testing/../run.py", 
>>> line 184, in 
>>>execfile(joinpath(tests_root, 'configs', test_filename + '.py'))  
>>> File 
>>> "/home/bpotter/Research/gem5/gem5-public-process/tests/testing/../configs/gpu-ruby.py",
>>>  line 282, in 
>>>Ruby.create_system(options, None, system)  File 
>>> "/home/bpotter/Research/gem5/gem5-public-process/configs/ruby/Ruby.py", 
>>> line 175, in create_system
>>>Network.init_network(options, network, InterfaceClass)  File 
>>> "/home/bpotter/Research/gem5/gem5-public-process/configs/network/Network.py",
>>>  line 108, in init_network
>>>network.setup_buffers()
>>>  File 
>>> "/home/bpotter/Research/gem5/gem5-public-process/src/mem/ruby/network/simple/SimpleNetwork.py",
>>>  line 62, in setup_buffers
>>>if link.dst_node == router:
>>>  File 
>>> "/home/bpotter/Research/gem5/gem5-public-process/src/python/m5/SimObject.py",
>>>  line 1105, in __getattr__
>>>raise AttributeError, err_string
>>> AttributeError: object 'SimpleIntLink' has no attribute 'dst_node'
>>>  (C++ object is not yet constructed, so wrapped C++ methods are 
>>> unavailable.)
>>> 
>>> `cat 
>>> build/HSAIL_X86/tests/opt/quick/se/60.gpu-randomtest/x86/linux/gpu-r
>>> andomtest-ruby-GPU_RfO/simerr`
>>> 
>>> warn: add_child('dst_node_'): child 'int_node' already has parent
>>> warn: add_child('dst_node_'): child 'int_node' already has parent
>>> warn: add_child('dst_node_'): child 'int_node' already has parent
>>> warn: add_child('dst_node_'): child 'dst_node_' already has parent 
>>> Traceback (most recent call last):
>>>  File "", line 1, in   File 
>>> "/home/bpotter/Research/gem5/gem5-public-process/src/python/m5/main.py", 
>>> line 400, in main
>>>exec filecode in scope
>>>  File 
>>> "/home/bpotter/Research/gem5/gem5-public-process/tests/testing/../run.py", 
>>> line 184, in 
>>>execfile(joinpath(tests_root, 'configs', test_filename + '.py'))  
>>> File 
>>> "/home/bpotter/Research/gem5/gem5-public-process/tests/testing/../configs/gpu-randomtest-ruby.py",
>>>  line 104, in 
>>>Ruby.create_system(options, False, system)  File 
>>> "/home/bpotter/Research/gem5/gem5-public-process/configs/ruby/Ruby.py", 
>>> line 175, in create_system
>>>Network.init_network(options, network, InterfaceClass)  File 
>>> "/home/bpotter/Research/gem5/gem5-public-process/configs/network/Network.py",
>>>  line 108, in init_network
>>>network.setup_buffers()
>>>  File 
>>> "/home/bpotter/Research/gem5/gem5-public-process/src/mem/ruby/network/simple/SimpleNetwork.py",
>>>  line 62, in setup_buffers
>>>if link.dst_node == router:
>>>  File 
>>> "/home/bpotter/Research/gem5/gem5-public-process/src/python/m5/SimObject.py",
>>>  line 1105, in __getattr__
>>>raise AttributeError, err_string
>>> AttributeError: object 'SimpleIntLink' has no attribute 'dst_node'
>>>  (C++ object is not yet constructed, so wrapped C++ methods are 
>>> unavailable.)
> 
> I would think this is "unrelated" in that it has nothing to do with the 
> import of Network.
> 
> 
> - Andreas
> 
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://revie

Re: [gem5-dev] changeset in gem5: x86, sim: add some syscalls to X86

[Gutierrez, Anthony]

Sorry, this all worked fine on my RHEL6 machine. I have a patch and am 
re-running the regressions on zizzer. Basically I'm adding unistd.h and 
changing the host call from pwrite64() => pwrite(), and I verified it can at 
least compile on zizzer now.

-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Andreas Hansson
Sent: Friday, August 05, 2016 1:25 AM
To: gem5 Developer List 
Subject: Re: [gem5-dev] changeset in gem5: x86, sim: add some syscalls to X86

Following up on this issue. For Linux it seems we get away with including 
unistd.h, but this only really masks the real problem: We should not use the 
transitional file access API (such as pwrite64), but rather stick to pwrite. 
OSX doesn’t even have the pwrite64 function in its libc implementation.

See e.g. This discussion around VLC:
https://mailman.videolan.org/pipermail/vlc-devel/2010-March/073937.html

Andreas

On 05/08/2016, 08:54, "gem5-dev on behalf of Andreas Hansson"
 wrote:

>Tony,
>
>It seems you killed gem5, literally. Beyond x86 the simulator does not 
>even compile.
>
>Andreas
>
>On 04/08/2016, 17:32, "gem5-dev on behalf of Tony Gutierrez"
> wrote:
>
>>changeset ba45735a726a in /z/repo/gem5
>>details: http://repo.gem5.org/gem5?cmd=changeset;node=ba45735a726a
>>description:
>>x86, sim: add some syscalls to X86
>>
>>this patch adds an implementation for the pwrite64 syscall and enables 
>>it for x86_64, and enables fstatfs for x86_64.
>>
>>diffstat:
>>
>> src/arch/x86/linux/process.cc |   4 ++--
>> src/sim/syscall_emul.hh   |  22 ++
>> 2 files changed, 24 insertions(+), 2 deletions(-)
>>
>>diffs (53 lines):
>>
>>diff -r 92509f1b24f7 -r ba45735a726a src/arch/x86/linux/process.cc
>>--- a/src/arch/x86/linux/process.ccWed Aug 03 11:10:46 2016 -0500
>>+++ b/src/arch/x86/linux/process.ccThu Aug 04 12:32:21 2016 -0400
>>@@ -236,7 +236,7 @@
>> /*  15 */ SyscallDesc("rt_sigreturn", unimplementedFunc),
>> /*  16 */ SyscallDesc("ioctl", ioctlFunc),
>> /*  17 */ SyscallDesc("pread64", unimplementedFunc),
>>-/*  18 */ SyscallDesc("pwrite64", unimplementedFunc),
>>+/*  18 */ SyscallDesc("pwrite64", pwrite64Func),
>> /*  19 */ SyscallDesc("readv", unimplementedFunc),
>> /*  20 */ SyscallDesc("writev", writevFunc),
>> /*  21 */ SyscallDesc("access", ignoreFunc), @@ -356,7 +356,7 @@
>> /* 135 */ SyscallDesc("personality", unimplementedFunc),
>> /* 136 */ SyscallDesc("ustat", unimplementedFunc),
>> /* 137 */ SyscallDesc("statfs", unimplementedFunc),
>>-/* 138 */ SyscallDesc("fstatfs", unimplementedFunc),
>>+/* 138 */ SyscallDesc("fstatfs", fstatfsFunc),
>> /* 139 */ SyscallDesc("sysfs", unimplementedFunc),
>> /* 140 */ SyscallDesc("getpriority", unimplementedFunc),
>> /* 141 */ SyscallDesc("setpriority", unimplementedFunc), diff -r 
>>92509f1b24f7 -r ba45735a726a src/sim/syscall_emul.hh
>>--- a/src/sim/syscall_emul.hhWed Aug 03 11:10:46 2016 -0500
>>+++ b/src/sim/syscall_emul.hhThu Aug 04 12:32:21 2016 -0400
>>@@ -1389,6 +1389,28 @@
>> return start;
>> }
>>
>>+template 
>>+SyscallReturn
>>+pwrite64Func(SyscallDesc *desc, int num, LiveProcess *p, 
>>+ThreadContext
>>*tc)
>>+{
>>+int index = 0;
>>+int tgt_fd = p->getSyscallArg(tc, index);
>>+Addr bufPtr = p->getSyscallArg(tc, index);
>>+int nbytes = p->getSyscallArg(tc, index);
>>+int offset = p->getSyscallArg(tc, index);
>>+
>>+int sim_fd = p->getSimFD(tgt_fd);
>>+if (sim_fd < 0)
>>+return -EBADF;
>>+
>>+BufferArg bufArg(bufPtr, nbytes);
>>+bufArg.copyIn(tc->getMemProxy());
>>+
>>+int bytes_written = pwrite64(sim_fd, bufArg.bufferPtr(), nbytes,
>>offset);
>>+
>>+return (bytes_written == -1) ? -errno : bytes_written; }
>>+
>> /// Target mmap() handler.
>> template 
>> SyscallReturn
>>___
>>gem5-dev mailing list
>>gem5-dev@gem5.org
>>http://m5sim.org/mailman/listinfo/gem5-dev
>
>IMPORTANT NOTICE: The contents of this email and any attachments are 
>confidential and may also be privileged. If you are not the intended 
>recipient, please notify the sender immediately and do not disclose the 
>contents to any other person, use it for any purpose, or store or copy 
>the information in any medium. Thank you.
>___
>gem5-dev mailing list
>gem5-dev@gem5.org
>http://m5sim.org/mailman/listinfo/gem5-dev

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.

Re: [gem5-dev] Gem5 APU Problem

[Gutierrez, Anthony]

Which benchmarks are you trying to build, how are you trying to build them, and 
what is the error? Please provide more details about the issues you are facing.

-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Wang Xu
Sent: Monday, July 18, 2016 12:33 PM
To: gem5-dev@gem5.org
Subject: [gem5-dev] Gem5 APU Problem

Hi, everyone
I am new to Gem5 APU. I tried to compile some benchmarks for HSAIL_X86 
simulation. I tried according to AMD MIRCO slides but it didn't work. Does 
anyone know how to get gpu-hello and gpu-hello-kernel.asm from gpu-hello.cpp 
and gpu-hello-kernel.asm?
Thanks
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Difference in i-cache accesses between dynamic and static linked binaries (SE mode)

[Gutierrez, Anthony]

Hi Dibakar,

It's not so surprising that dynamic vs. static binaries show some difference in 
instruction fetch behavior, however these numbers do seem drastic, and also 
seem counter intuitive as I would expect a dynamic binary to have more accesses 
due to trampoline calls. Have you looked at the number of branch and i-cache 
misses between the two? Also the number of CPU fetches?

The static binary will certainly be larger if you're compiling in all those 
libs and will occupy more space in memory, but libquantum doesn’t make many 
library calls and it seems you're only running a single process so we won't 
have redundant library code in memory. I could only imagine this happening if 
somehow library code were getting mixed with the application code in the same 
cache line - e.g., because the linker is somehow inlining some of the library 
calls - thus causing more fetches to the i-cache, whereas the dynamically 
linked binary may be serving most of its fetches out of the fetch buffer.

-Tony

-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Dibakar Gope
Sent: Monday, May 30, 2016 9:06 AM
To: gem5-dev@gem5.org
Subject: [gem5-dev] Difference in i-cache accesses between dynamic and static 
linked binaries (SE mode)

Hi All,


I was trying with these new dynamic linking patches for SE mode posted by 
Brandon Potter. I am doing some dry run with the libquantum (spec cpu 2006) 
workload. So I have two binaries for libquantum --- one with static linking and 
the other with dynamic linking. However I am finding some huge differences in 
I-cache accesses with running these two binaries. I am running x86 with 
classing memory model. Here are the difference in stats between these two runs:


static libquantum binary (flags used while compiling: -static -m64 -Os 
-mfpmath=sse -msse3):

$ ldd ./libquantum_base.amd64-m64-gcc41-nn_static_link
not a dynamic executable


commandline: ./build/X86/gem5.opt configs/example/se.py --caches --l2cache 
--cmd=./libquantum_base.amd64-m64-gcc41-nn_static_link  -o "15 2" 
--cpu-type=detailed


system.cpu.icache.overall_accesses::cpu.inst  2386350   
# number of overall (read+write) accesses
system.cpu.commit.committedInsts 14339244   # 
Number of instructions committed
system.cpu.commit.committedOps   23640619   # 
Number of ops (including micro ops) committed
system.cpu.ipc   1.359009   # 
IPC: Instructions Per Cycle
sim_seconds  0.005276   # 
Number of seconds simulated
system.cpu.fetch.Branches 3780944   # 
Number of branches that fetch encountered
system.cpu.fetch.predictedBranches2249794   # 
Number of branches that fetch has predicted taken




dynamic libquantum binary (flags used while compiling: -m64 -Os -mfpmath=sse 
-msse3):


$ ldd ./libquantum_base.amd64-m64-gcc41-nn_dyn_link
linux-vdso.so.1 =>  (0x7ffc62d28000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f18608c)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f186050)
/lib64/ld-linux-x86-64.so.2 (0x7f1860bc)



commandline: ./build/X86/gem5.opt configs/example/se.py --caches --l2cache 
--cmd=./libquantum_base.amd64-m64-gcc41-nn_dyn_link  -o "15 2" 
--cpu-type=detailed

system.cpu.icache.overall_accesses::cpu.inst   840649   
# number of overall (read+write) accesses
system.cpu.commit.committedInsts 14503123   # 
Number of instructions committed
system.cpu.commit.committedOps   23942141   # 
Number of ops (including micro ops) committed
system.cpu.ipc   1.346305   # 
IPC: Instructions Per Cycle
sim_seconds  0.005386   # 
Number of seconds simulated
system.cpu.fetch.Branches 3846406   # 
Number of branches that fetch encountered
system.cpu.fetch.predictedBranches2283756   # 
Number of branches that fetch has predicted taken

So I was wondering why there is such a huge difference between i-cache accesses 
(2386350 with static vs. 840649 with dynamic linking) among these two runs 
although the ipc and total committed instructions are almost same. Any thoughts?

Thanks,
Dibakar Gope
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] changeset in gem5: ruby: send address ranges from RubyPort

[Gutierrez, Anthony]

I see. I have limited understanding of that code, so I was trying to fix the 
error and really didn't know the intention of the code. I guess what should 
have happened is that the DMASequencer should have simply kept its slave port, 
and initialized it the way it always had. I can make that change.

-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Joel Hestness
Sent: Wednesday, February 17, 2016 10:45 AM
To: gem5 Developer List 
Subject: Re: [gem5-dev] changeset in gem5: ruby: send address ranges from 
RubyPort

Sorry for piling on, but here's a little more: Arguably, what should happen is 
that the DMASequencer should have its own address-routing-capable slave port 
separate from the standard slave ports of the RubyPort. I suspect this is a 
major reason why Nilay had previously disconnected the inheritance.

  Joel


On Wed, Feb 17, 2016 at 12:42 PM, Joel Hestness 
wrote:

> Hi Tony,
>   Thank you for clarifying. Unfortunately, I feel that this is an 
> inappropriate solution. Prior to changing the DMASequencer back to 
> descending from RubyPort, none of the sequencers/coalescers needed to 
> send range changes, because none are ever used to connect to 
> address-routed components. With this change, the prior types will now 
> all send unnecessary range updates, when only the DMASequencer should 
> do this (it is the only that can/should be connected to address-routed 
> components). I can understand that you didn't intend for your change 
> to cause this, but it effectively changes the interface of 
> sequencers/coalescers.
>
>   I feel strongly that this should be handled a different way, because 
> this is the sort of change that has gotten us into our terrible 
> sequencer/coalescer inheritance mess. Namely, there is poor 
> delineation/inheritance among the existing types, which causes poorer 
> derivative changes that further blur the lines/interfaces.
>
>   I would recommend that you make the slave_ports visible to inherited 
> types and just send the range change from DMASequencer::init(). This 
> shouldn't cause any code duplication, as you suggest.
>
>   Thank you,
>   Joel
>
>
> On Wed, Feb 17, 2016 at 11:22 AM, Gutierrez, Anthony < 
> anthony.gutier...@amd.com> wrote:
>
>> The sequencer originally did this because it maintained its own slave 
>> port, because it wasn't derived from RubyPort. Now that it is, it no 
>> longer has its own slave port, instead using RubyPorts slave_ports vector.
>> RubyPort didn't send the ranges for the slave_ports, and it is 
>> private, so any derived class, e.g., DMASequencer, cannot do it in 
>> its own init() function.
>>
>> By inspecting the code, it seemed that no derived classes of RubyPort 
>> utilized the slave_ports vector in the RubyPort base class, which is 
>> why this assert isn't being hit previously.
>>
>> Also, in general we'd like to keep common functionality in the base 
>> RubyPort to avoid code duplication. If I made slave_ports protected, 
>> I could send the range change via the init() call in the derived 
>> classes, but there really is no point in doing that as it would be pure code 
>> dupe.
>>
>> -Original Message-
>> From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Joel 
>> Hestness
>> Sent: Wednesday, February 17, 2016 9:06 AM
>> To: gem5 Developer List 
>> Cc: gem5-...@m5sim.org
>> Subject: Re: [gem5-dev] changeset in gem5: ruby: send address ranges 
>> from RubyPort
>>
>> Hi Tony,
>>   Thanks for taking a look at the regression problem. I'm a little 
>> confused about this fix though: The sendRangeChange() call was 
>> originally in the DMASequencer, but not in the RubyPort. Here, you've 
>> added it in the RubyPort. Shouldn't this have been put back into 
>> DMASequencer::init() instead?
>>
>>   Thanks!
>>   Joel
>>
>>
>> On Wed, Feb 17, 2016 at 10:32 AM, Tony Gutierrez < 
>> anthony.gutier...@amd.com>
>> wrote:
>>
>> > changeset e777659dcff6 in /z/repo/gem5
>> > details: http://repo.gem5.org/gem5?cmd=changeset;node=e777659dcff6
>> > description:
>> > ruby: send address ranges from RubyPort
>> >
>> > diffstat:
>> >
>> >  src/mem/ruby/system/RubyPort.cc |  3 +++
>> >  1 files changed, 3 insertions(+), 0 deletions(-)
>> >
>> > diffs (13 lines):
>> >
>> > diff -r a4d19e7cd26d -r e777659dcff6 src/mem/ruby/system/RubyPort.cc
>> > --- a/src/mem/ruby/system/RubyPort.cc   Wed Feb 17 03:56:20 2016 -0500
>> > +++ b/src/mem/ruby/syst

Re: [gem5-dev] changeset in gem5: ruby: send address ranges from RubyPort

[Gutierrez, Anthony]

The sequencer originally did this because it maintained its own slave port, 
because it wasn't derived from RubyPort. Now that it is, it no longer has its 
own slave port, instead using RubyPorts slave_ports vector. RubyPort didn't 
send the ranges for the slave_ports, and it is private, so any derived class, 
e.g., DMASequencer, cannot do it in its own init() function.

By inspecting the code, it seemed that no derived classes of RubyPort utilized 
the slave_ports vector in the RubyPort base class, which is why this assert 
isn't being hit previously.

Also, in general we'd like to keep common functionality in the base RubyPort to 
avoid code duplication. If I made slave_ports protected, I could send the range 
change via the init() call in the derived classes, but there really is no point 
in doing that as it would be pure code dupe.

-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Joel Hestness
Sent: Wednesday, February 17, 2016 9:06 AM
To: gem5 Developer List 
Cc: gem5-...@m5sim.org
Subject: Re: [gem5-dev] changeset in gem5: ruby: send address ranges from 
RubyPort

Hi Tony,
  Thanks for taking a look at the regression problem. I'm a little confused 
about this fix though: The sendRangeChange() call was originally in the 
DMASequencer, but not in the RubyPort. Here, you've added it in the RubyPort. 
Shouldn't this have been put back into DMASequencer::init() instead?

  Thanks!
  Joel


On Wed, Feb 17, 2016 at 10:32 AM, Tony Gutierrez 
wrote:

> changeset e777659dcff6 in /z/repo/gem5
> details: http://repo.gem5.org/gem5?cmd=changeset;node=e777659dcff6
> description:
> ruby: send address ranges from RubyPort
>
> diffstat:
>
>  src/mem/ruby/system/RubyPort.cc |  3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
>
> diffs (13 lines):
>
> diff -r a4d19e7cd26d -r e777659dcff6 src/mem/ruby/system/RubyPort.cc
> --- a/src/mem/ruby/system/RubyPort.cc   Wed Feb 17 03:56:20 2016 -0500
> +++ b/src/mem/ruby/system/RubyPort.cc   Wed Feb 17 11:31:54 2016 -0500
> @@ -84,6 +84,9 @@
>  {
>  assert(m_controller != NULL);
>  m_mandatory_q_ptr = m_controller->getMandatoryQueue();
> +
> +for (const auto &s_port : slave_ports)
> +s_port->sendRangeChange();
>  }
>
>  BaseMasterPort &
> ___
> gem5-dev mailing list
> gem5-dev@gem5.org
> http://m5sim.org/mailman/listinfo/gem5-dev
>



--
  Joel Hestness
  PhD Candidate, Computer Architecture
  Dept. of Computer Science, University of Wisconsin - Madison
  http://pages.cs.wisc.edu/~hestness/
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Failing Ruby regression

[Gutierrez, Anthony]

I just pushed a fix.

-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Andreas Hansson
Sent: Tuesday, February 16, 2016 1:16 AM
To: gem5-dev@gem5.org
Subject: [gem5-dev] Failing Ruby regression

Hi all,

With the push of:

changeset:   11339:c45bfadcd51b
user:Michael LeBeane 
date:Sun Feb 14 20:28:48 2016 -0500
summary: ruby: make DMASequencer inherit from RubyPort

The following regression fails:

* 
build/X86_MESI_Two_Level/tests/opt/long/fs/10.linux-boot/x86/linux/pc-simple-timing-ruby-MESI_Two_Level
 FAILED!

Andreas
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Failing Ruby regression

[Gutierrez, Anthony]

Sorry, I ran quick only before pushing this. We're looking into it.

-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Andreas Hansson
Sent: Tuesday, February 16, 2016 1:16 AM
To: gem5-dev@gem5.org
Subject: [gem5-dev] Failing Ruby regression

Hi all,

With the push of:

changeset:   11339:c45bfadcd51b
user:Michael LeBeane 
date:Sun Feb 14 20:28:48 2016 -0500
summary: ruby: make DMASequencer inherit from RubyPort

The following regression fails:

* 
build/X86_MESI_Two_Level/tests/opt/long/fs/10.linux-boot/x86/linux/pc-simple-timing-ruby-MESI_Two_Level
 FAILED!

Andreas
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] Another style guide suggestion on the use of unsigned types.

[Gutierrez, Anthony]

Since we've been discussing style/coding standards lately, I thought it would 
be a good time to bring up a long-standing gripe I have: the use of unsigned 
types. I'd like to suggest that the style guide mandate that the use of 
unsigned types is forbidden unless there is an explicit need for it (note I 
don't believe that "this variable ought never be negative" is a good reason). 
Good use cases would be when we're doing bitwise operations/masking, we need 
well defined overflow behavior, or we need the extra bit of precision, e.g., 
addresses.

This is already mandated in the style guide of companies like Google: 
https://google.github.io/styleguide/cppguide.html#Integer_Types, and I think 
it's generally accepted as good software engineering practice.

Also, as a somewhat related issue, I propose mandating that we shouldn't 
specify precision using the uint*_t/int*_t flavors unless we need explicit 
precision, and in many of those cases we should typedef these things, as in 
Addr.

Thoughts?
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Explicit boolean comparisons (== true/== false)

[Gutierrez, Anthony]

I also vote in favor of adding this mandate to the style guide, and enforcing 
it in the style checker.

-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Andreas Sandberg
Sent: Friday, January 29, 2016 1:30 AM
To: gem5 Developer List 
Subject: Re: [gem5-dev] Explicit boolean comparisons (== true/== false)

+1. I find explicit boolean comparisons pretty ugly myself.

//Andreas

On 28/01/2016, 23:19, "gem5-dev on behalf of Steve Reinhardt"
 wrote:

>I've noticed that some code has crept in that uses explicit boolean 
>comparisons in conditionals.  Examples are given below.  I know we've 
>gotten rid of these in the past (see for example 
>http://reviews.gem5.org/r/2281).  I'd like to update the style guide to 
>make it clear that this is not desirable, and ideally add a check for 
>this to the style checker.
>
>Obviously some people like this style and think it improves readability.
>While I personally disagree, and think that there are several reasons 
>why these checks aren't a good idea, I hope it's sufficient to point 
>out that it creates a big inconsistency when some checks are written 
>this way and others are not.  Since we're not about to go adding these 
>explicit comparisons everywhere, we should consistently not use them.
>
>Any comments?
>
>Steve
>
>
>src/cpu/base.cc:if(monitor.gotWakeup == false) {
>src/cpu/base.cc.orig:if (monitor.gotWakeup == false) {
>src/dev/net/dist_iface.cc:assert(recvDone->scheduled() == false);
>src/dev/net/dist_iface.cc:assert(ckptRestore == false);
>src/arch/x86/utility.cc: !(i > MISCREG_CR8 && i <=
>MISCREG_CR15) ) == false) {
>src/arch/hsail/insts/decl.hh:if (src[i].isVectorRegister()
>== true) {
>src/arch/hsail/insts/decl.hh:if (src0.isVectorRegister() ==
>true) {
>src/arch/hsail/insts/decl.hh:if (src1.isVectorRegister() ==
>true) {
>src/arch/hsail/insts/decl.hh:if (src2.isVectorRegister() ==
>true) {
>src/arch/hsail/insts/decl.hh:if (src0.isVectorRegister() ==
>true) {
>src/arch/hsail/insts/decl.hh:if (src1.isVectorRegister() ==
>true) {
>src/arch/hsail/insts/mem.hh:if (src[i].isVectorRegister()
>== true) {
>src/mem/ruby/network/garnet/fixed-pipeline/SWallocator_d.cc:
> m_router->curCycle()) == false);
>src/mem/ruby/system/GPUCoalescer.cc:if (deadlockCheckEvent.scheduled()
>== false) {
>src/mem/ruby/common/WriteMask.hh:return mMask[offset] == true;
>___
>gem5-dev mailing list
>gem5-dev@gem5.org
>http://m5sim.org/mailman/listinfo/gem5-dev

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] On ReviewBoard: dist-gem5, the integration of multi-gem5 and pd-gem5

[Gutierrez, Anthony]

It looks like you took care of all issues. If nobody objects by the end of the 
week, I will commit them during the weekend.

From: Mohammad Alian [mailto:al...@wisc.edu]
Sent: Wednesday, January 20, 2016 9:51 AM
To: gem5 Developer List ; Gutierrez, Anthony 

Subject: Re: [gem5-dev] On ReviewBoard: dist-gem5, the integration of 
multi-gem5 and pd-gem5

Hi everyone,
For now, I feel these two patches are good enough to be committed as there is 
no open issues and they were on RB long enough.

http://reviews.gem5.org/r/3230/
http://reviews.gem5.org/r/3231/

Because I don't have commit access, can anybody commit them on my behalf?
Thank you,
Mohammad


On Fri, Jan 8, 2016 at 10:57 AM, Mohammad Alian 
mailto:al...@wisc.edu>> wrote:
Hi everyone,
To provide the full distributed simulation feature available to the public, we 
would like to commit the rest of dist-gem5 patches asap (by the end of next 
week, Jan-15, if there is no issues). Please have a look at these two patches:

http://reviews.gem5.org/r/3230/
http://reviews.gem5.org/r/3231/
Thank you,
Mohammad
On Thu, Dec 10, 2015 at 2:53 PM, Curtis Dunham 
mailto:curtis.dun...@arm.com>> wrote:
Hi everyone,
Hopefully some of you were able to attend the tutorial at MICRO where we 
presented our work on dist-gem5.  We would like to get it pushed into the tree 
by the end of next week (Fri Dec 18), so please have a look!

http://reviews.gem5.org/r/3227/
http://reviews.gem5.org/r/3228/
http://reviews.gem5.org/r/3229/
http://reviews.gem5.org/r/3230/
http://reviews.gem5.org/r/3231/


Curtis

-Original Message-
From: gem5-dev 
[mailto:gem5-dev-boun...@gem5.org<mailto:gem5-dev-boun...@gem5.org>] On Behalf 
Of Mohammad Alian
Sent: Thursday, November 19, 2015 2:24 PM
To: gem5 Developer List
Subject: Re: [gem5-dev] On ReviewBoard: dist-gem5, the integration of 
multi-gem5 and pd-gem5
Thank you Curtis for the announcement. Here are the rest of patches:

http://reviews.gem5.org/r/3230/
http://reviews.gem5.org/r/3231/

Thanks,
Mohammad

On Thu, Nov 19, 2015 at 11:59 AM, Curtis Dunham 
mailto:curtis.dun...@arm.com>>
wrote:

> Hello everyone,
>
> I've posted part of a collaboration with the University of Wisconsin to
> combine our separate efforts towards a distributed simulation
> infrastructure for gem5, multi-gem5 and pd-gem5 respectively, into a
> unified solution we call dist-gem5.
>
>
>
> Again, these are only part of the solution; patches from Wisconsin should
> be posted shortly as well. :-)
> http://reviews.gem5.org/r/3227/
> http://reviews.gem5.org/r/3228/
> http://reviews.gem5.org/r/3229/
>
>
> Curtis
>
> 
>
> -- IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
> ___
> gem5-dev mailing list
> gem5-dev@gem5.org<mailto:gem5-dev@gem5.org>
> http://m5sim.org/mailman/listinfo/gem5-dev
>
___
gem5-dev mailing list
gem5-dev@gem5.org<mailto:gem5-dev@gem5.org>
http://m5sim.org/mailman/listinfo/gem5-dev
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
gem5-dev mailing list
gem5-dev@gem5.org<mailto:gem5-dev@gem5.org>
http://m5sim.org/mailman/listinfo/gem5-dev


___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] Slides available from MICRO-48 tutorial on AMD's APU model in gem5.

[Gutierrez, Anthony]

Hello All,

As many of you probably know we (AMD) recently made our APU/compute-GPU model 
publically available, and it should be pushed to the gem5 source tree soon. We 
also hosted a very successful tutorial on our APU model at MICRO-48 on December 
6th. We've had a lot of requests for our slides so we decided to make them 
publically available here:

http://gem5.org/gpu_models

This page will eventually contains lots more documentation on the model and how 
to use it.

Thanks,
Tony
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Cron /z/m5/regression/do-regression quick

[Gutierrez, Anthony]

I think these ran before I pushed the latest changeset. They were all "CHANGED" 
when I ran manually, but none failed. They should be ok the next time the 
tester runs. I'll update the stats too.


From: gem5-dev  on behalf of Cron Daemon 

Sent: Saturday, December 12, 2015 12:09 AM
To: gem5-dev@gem5.org
Subject: [gem5-dev] Cron  /z/m5/regression/do-regression quick

* build/ALPHA/tests/opt/quick/se/60.rubytest/alpha/linux/rubytest-ruby 
FAILED!
* 
build/ALPHA_MOESI_hammer/tests/opt/quick/se/60.rubytest/alpha/linux/rubytest-ruby-MOESI_hammer
 FAILED!
* 
build/ALPHA_MESI_Two_Level/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby-MESI_Two_Level
 passed.* 
build/ALPHA_MESI_Two_Level/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing-ruby-MESI_Two_Level
 passed.* 
build/ALPHA_MESI_Two_Level/tests/opt/quick/se/60.rubytest/alpha/linux/rubytest-ruby-MESI_Two_Level
 FAILED!
* 
build/ALPHA_MOESI_CMP_directory/tests/opt/quick/se/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_directory
 FAILED!
* 
build/ALPHA_MOESI_CMP_token/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_token
 passed.* 
build/ALPHA_MOESI_CMP_token/tests/opt/quick/se/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_token
 FAILED!* 
build/ALPHA_MOESI_CMP_token/tests/opt/quick/se/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_token
 passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/minor-timing passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/o3-timing passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/simple-timing passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/minor-timing passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/simple-atomic passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/simple-timing-ruby 
passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/o3-timing passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/simple-atomic passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing-ruby 
passed.
* build/ALPHA/tests/opt/quick/se/01.hello-2T-smt/alpha/linux/o3-timing-mt 
passed.
* 
build/ALPHA/tests/opt/quick/se/03.learning-gem5/alpha/linux/learning-gem5-p1-simple
 passed.
* 
build/ALPHA/tests/opt/quick/se/03.learning-gem5/alpha/linux/learning-gem5-p1-two-level
 passed.
* build/ALPHA/tests/opt/quick/se/20.eio-short/alpha/eio/simple-atomic 
passed.
* build/ALPHA/tests/opt/quick/se/20.eio-short/alpha/eio/simple-timing 
passed.
* build/ALPHA/tests/opt/quick/se/30.eio-mp/alpha/eio/simple-atomic-mp 
passed.
* build/ALPHA/tests/opt/quick/se/30.eio-mp/alpha/eio/simple-timing-mp 
passed.
 * build/ALPHA/tests/opt/quick/se/30.eon/alpha/tru64/simple-atomic passed.
* build/ALPHA/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby passed.
* build/ALPHA/tests/opt/quick/se/50.vortex/alpha/tru64/simple-atomic passed.
* build/ALPHA/tests/opt/quick/se/50.vortex/alpha/tru64/simple-timing passed.
* build/ALPHA/tests/opt/quick/se/70.twolf/alpha/tru64/simple-atomic passed.
* build/ALPHA/tests/opt/quick/se/70.twolf/alpha/tru64/simple-timing passed.
* 
build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-atomic 
passed.
* 
build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-atomic-dual
 passed.
* 
build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-timing 
passed.
* 
build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-timing-dual
 passed.
* 
build/ALPHA/tests/opt/quick/fs/80.netperf-stream/alpha/linux/twosys-tsunami-simple-atomic
 passed.
* 
build/ALPHA_MOESI_hammer/tests/opt/quick/se/00.hello/alpha/linux/simple-timing-ruby-MOESI_hammer
 passed.* 
build/ALPHA_MOESI_hammer/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing-ruby-MOESI_hammer
 passed.
* 
build/ALPHA_MOESI_hammer/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby-MOESI_hammer
 passed.
* 
build/ALPHA_MESI_Two_Level/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby-MESI_Two_Level
 passed.* 
build/ALPHA_MESI_Two_Level/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing-ruby-MESI_Two_Level
 passed.* 
build/ALPHA_MESI_Two_Level/tests/opt/quick/se/60.rubytest/alpha/linux/rubytest-ruby-MESI_Two_Level
 FAILED!
* 
build/ALPHA_MESI_Two_Level/tests/opt/quick/se/00.hello/alpha/linux/simple-timing-ruby-MESI_Two_Level
 passed.
* 
build/ALPHA_MOESI_CMP_directory/tests/opt/quick/se/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_directory
 passed.
* 
build/ALPHA_MOESI_CMP_directory/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_directory
 passed.
* 
build/ALPHA_MOESI_CMP_directory/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby-MOESI_CMP_directory
 passed.

Re: [gem5-dev] Cron /z/m5/regression/do-regression quick

[Gutierrez, Anthony]

Yeah, there was a companion patch to the one I pushed that should have been 
folded first. Sorry, I'll take care of it.

-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Andreas Hansson
Sent: Friday, December 11, 2015 6:59 AM
To: gem5 Developer List 
Subject: Re: [gem5-dev] Cron  /z/m5/regression/do-regression 
quick

Tony, I suspect this is your RubyTester patch breaking things...

Andreas

On 11/12/2015, 09:17, "gem5-dev on behalf of Cron Daemon"
 wrote:

>*
>build/ALPHA/tests/opt/quick/se/60.rubytest/alpha/linux/rubytest-ruby
>FAILED!
>*
>build/ALPHA_MOESI_hammer/tests/opt/quick/se/60.rubytest/alpha/linux/rub
>yte
>st-ruby-MOESI_hammer FAILED!
>*
>build/ALPHA_MESI_Two_Level/tests/opt/quick/se/60.rubytest/alpha/linux/r
>uby
>test-ruby-MESI_Two_Level FAILED!
>*
>build/ALPHA_MOESI_CMP_directory/tests/opt/quick/se/60.rubytest/alpha/li
>nux /rubytest-ruby-MOESI_CMP_directory FAILED!
>*
>build/ALPHA_MOESI_CMP_token/tests/opt/quick/se/60.rubytest/alpha/linux/
>rub
>ytest-ruby-MOESI_CMP_token FAILED!
>scons: *** Error 134
>scons: *** Error 134
>scons: *** Error 134
>scons: *** Error 134
>scons: *** Error 134
>* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/simple-atomic
>passed.
>* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/minor-timing
>passed.
>* 
>build/ALPHA/tests/opt/quick/se/20.eio-short/alpha/eio/simple-atomic
>passed.
>* build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/simple-atomic
>passed.
>* 
>build/ALPHA/tests/opt/quick/se/30.eio-mp/alpha/eio/simple-timing-mp
>passed.
>*
>build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple
>-at
>omic passed.
>*
>build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple
>-at
>omic-dual passed.
>*
>build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/simple-timing-ruby
>passed.
>* build/ALPHA/tests/opt/quick/se/70.twolf/alpha/tru64/simple-atomic
>passed.
>*
>build/ALPHA/tests/opt/quick/se/03.learning-gem5/alpha/linux/learning-ge
>m5-
>p1-simple passed.
>* 
>build/ALPHA/tests/opt/quick/se/30.eio-mp/alpha/eio/simple-atomic-mp
>passed.
>* build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing
>passed.
>* 
>build/ALPHA/tests/opt/quick/se/50.vortex/alpha/tru64/simple-atomic
>passed.
>* build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/minor-timing
>passed.
>*
>build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple
>-ti
>ming-dual passed.
>* 
>build/ALPHA/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby
>passed.
>* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/simple-timing
>passed.
>*
>build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing-ruby
>passed.
>* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/o3-timing
>passed.
>* 
>build/ALPHA/tests/opt/quick/se/20.eio-short/alpha/eio/simple-timing
>passed.
>*
>build/ALPHA/tests/opt/quick/se/01.hello-2T-smt/alpha/linux/o3-timing-mt
>passed.
>*
>build/ALPHA/tests/opt/quick/se/03.learning-gem5/alpha/linux/learning-ge
>m5-
>p1-two-level passed.
>* 
>build/ALPHA/tests/opt/quick/se/50.vortex/alpha/tru64/simple-timing
>passed.
>* build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/o3-timing
>passed.
>*
>build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple
>-ti
>ming passed.
>* build/ALPHA/tests/opt/quick/se/70.twolf/alpha/tru64/simple-timing
>passed.
>*
>build/ALPHA_MOESI_hammer/tests/opt/quick/se/00.hello/alpha/tru64/simple
>-ti
>ming-ruby-MOESI_hammer passed.
>*
>build/ALPHA_MOESI_hammer/tests/opt/quick/se/00.hello/alpha/linux/simple
>-ti
>ming-ruby-MOESI_hammer passed.
>* build/ALPHA/tests/opt/quick/se/30.eon/alpha/tru64/simple-atomic
>passed.
>*
>build/ALPHA_MOESI_hammer/tests/opt/quick/se/50.memtest/alpha/linux/memt
>est
>-ruby-MOESI_hammer passed.
>*
>build/ALPHA_MESI_Two_Level/tests/opt/quick/se/00.hello/alpha/tru64/simp
>le-
>timing-ruby-MESI_Two_Level passed.
>*
>build/ALPHA_MESI_Two_Level/tests/opt/quick/se/00.hello/alpha/linux/simp
>le-
>timing-ruby-MESI_Two_Level passed.
>*
>build/ALPHA_MESI_Two_Level/tests/opt/quick/se/50.memtest/alpha/linux/me
>mte
>st-ruby-MESI_Two_Level passed.
>*
>build/ALPHA_MOESI_CMP_directory/tests/opt/quick/se/00.hello/alpha/tru64
>/si mple-timing-ruby-MOESI_CMP_directory passed.
>*
>build/ALPHA_MOESI_CMP_directory/tests/opt/quick/se/00.hello/alpha/linux
>/si mple-timing-ruby-MOESI_CMP_directory passed.
>*
>build/ALPHA/tests/opt/quick/fs/80.netperf-stream/alpha/linux/twosys-tsu
>nam
>i-simple-atomic passed.
>*
>build/ALPHA_MOESI_CMP_token/tests/opt/quick/se/00.hello/alpha/tru64/sim
>ple
>-timing-ruby-MOESI_CMP_token passed.
>*
>build/ALPHA_MOESI_CMP_token/tests/opt/quick/se/00.hello/alpha/linux/sim
>ple
>-timing-ruby-MOESI_CMP_token passed.
>*
>build/ALPHA_MOESI_CMP_directory/tests/opt/quick/se/50.memtest/alpha/lin
>ux/ memtest-ruby-MOESI_CMP_directory passed

Re: [gem5-dev] Style Checker: Includes Order Warning

[Gutierrez, Anthony]

I see these changes were pushed around Feb 2015, but can you point to the rb 
posts? I am unable to find them in your history.

-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Andreas Sandberg
Sent: Friday, November 20, 2015 8:36 AM
To: gem5 Developer List
Subject: Re: [gem5-dev] Style Checker: Includes Order Warning

Joe,

This is an unfortunate mis-match between the style checker and the wiki.
The style checker is right in this case. I have updated the wiki to reflect 
this behavior.

The reason for this new include order is that it ensures that header files are 
independent. I.e., you¹ll never depend on the include order to get a header to 
compile.

//Andreas

On 19/11/2015, 20:22, "gem5-dev on behalf of Gross, Joe"
 wrote:

>Andreas,
>
>I'm running 11220:c0ea80fed78f, which should be the tip. It seems to 
>happen after a qpush, which is a commit.
>
>Joe
>
>
>From: gem5-dev  on behalf of Andreas Hansson 
>
>Sent: Thursday, November 19, 2015 2:33 AM
>To: gem5 Developer List
>Subject: Re: [gem5-dev] Style Checker: Includes Order Warning
>
>Hi Joe,
>
>This should be fixed (by Andreas Sandberg). Are you using an up-to-date 
>repo?
>
>Andreas
>
>On 19/11/2015, 06:48, "gem5-dev on behalf of Gross, Joe"
> wrote:
>
>>Hello,
>>
>>When working with mq patches in the gem5 repo, I get a lot of warnings 
>>about the order of includes being wrong. Although they follow the 
>>guidelines set in the style guide, it seems that the script is looking 
>>for something different.
>>
>>When directing the script to fix them, it will put the include for 
>>XX.hh first if the file is XX.cc. It's unclear what causes this, but 
>>several others have observed this behavior and have to choose ignore 
>>many times in the course of applying patches.
>>
>>Is there some way to disable this portion of the style checker so that 
>>we don't have to manually override it all the time? Thanks.
>>
>>Joe
>>___
>>gem5-dev mailing list
>>gem5-dev@gem5.org
>>http://m5sim.org/mailman/listinfo/gem5-dev
>
>
>
>
>-- IMPORTANT NOTICE: The contents of this email and any attachments are 
>confidential and may also be privileged. If you are not the intended 
>recipient, please notify the sender immediately and do not disclose the 
>contents to any other person, use it for any purpose, or store or copy 
>the information in any medium. Thank you.
>___
>gem5-dev mailing list
>gem5-dev@gem5.org
>http://m5sim.org/mailman/listinfo/gem5-dev
>___
>gem5-dev mailing list
>gem5-dev@gem5.org
>http://m5sim.org/mailman/listinfo/gem5-dev




-- IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] Fix DPRINTs to reflect Address to Addr change

[Gutierrez, Anthony]

Nilay,

The Address to Addr patch changed the formatting of the DPRINTs that used 
Address, will you submit a change that addresses this by making them print 
statements behave exactly as before?

Thanks,
Tony
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] changeset in gem5: syscall: Add readlink to x86 with special cas...

[Gutierrez, Anthony]

My point is, there are only 2 options as far as I see it: disallow its use, or 
something like the solution we proposed. Obviously we can’t disallow its use 
any more than we can disallow users having multiple runs using the same binary 
only with a different name. The way the simulator is used can affect its 
output, and this is outside of our control. However, this is a valid use and 
this is the correct behavior.

I can’t think of any other way to allow binaries to run from any location and 
have the path not effect simulation. Besides that, if binaries are run from 
different paths then readlink() should behave this way, so it’s more accurate 
in that respect. Because of this, we chose to implement it this way. If anyone 
else has a better solution, it would be welcome.

For anything regression related, or runs that produce reference output, we 
always use the same paths/workloads etc. For debugging purposes I always use 
the same setup on my own machine. I can see how this can be an issue in the 
rare case where a bug is not caught by debugging or regressions, and only 
manifests during an actual simulation run on a cluster, however I don’t have 
good answer for that.

From: Joel Hestness [mailto:jthestn...@gmail.com]
Sent: Wednesday, September 09, 2015 11:14 AM
To: Gutierrez, Anthony
Cc: gem5 Developer List; Hashe, David; Che, Shuai
Subject: Re: [gem5-dev] changeset in gem5: syscall: Add readlink to x86 with 
special cas...


If any codes use readlink() in this way, they need the correct path, and not 
gem5’s path. This isn’t non-determinism, the runs will always be the same given 
the binaries are in the same path. I’m not sure how this can be solved other 
than to say we won’t allow codes to use readlink() this way.

It's not a viable solution to just disallow this kind of use, though. GLIBC 
uses readlink, which gets compiled into some static binaries, so a gem5 user 
may not have control over the use of readlink. A simple example where this 
fails is if I run simulations on a cluster with a different directory structure 
than machines I can use to debug. The difference in directory structure is 
enough so that the cluster runs cannot be replicated on other machines.


Using readlink() on /proc/self/exe would return the path to the gem5 binary 
previously, as opposed to the binary running inside of gem5. We noticed this 
because some of our codes used readlink() this way to figure out their paths.

Sure. Can you explain how you are running simulations such that you don't need 
to worry about simulations being replicable in different settings? Are you 
always able to debug simulations in the exact same setting where you discovered 
a bug?

  Joel



From: Joel Hestness [mailto:jthestn...@gmail.com<mailto:jthestn...@gmail.com>]
Sent: Wednesday, September 09, 2015 10:32 AM
To: gem5 Developer List; Hashe, David; Che, Shuai; Gutierrez, Anthony
Subject: Re: [gem5-dev] changeset in gem5: syscall: Add readlink to x86 with 
special cas...

Hey David, Shuai, and Tony,

  It appears that this patch can introduce simulator non-determinism due to the 
use of Process::progName(). Basically, if benchmark paths are changed (e.g. 
running on a different system), then the string copy operations in the 
"/proc/self/exe" codepath can create strings of different lengths. As a result, 
readlink can return different values depending on the progName() and cause the 
simulated benchmark to behave differently. This is problematic when trying to 
replicate sims for regressions or debugging.

  It looks like this patch aims to address changes in GLIBC, which now uses 
readlink to find the binary before handling environment variables (in 
_dl_non_dynamic_init<http://osxr.org/glibc/source/elf/dl-support.c#0312>). That 
said, I'm not clear how this patch is supposed to fix problems or how we can 
avoid the nondeterminism it introduces. Can you guys elaborate on how this 
change is intended to work (e.g. what is the use case you were aiming for)?

  Thank you,
  Joel



On Sat, Aug 1, 2015 at 11:07 AM, David Hashe 
mailto:david.ha...@amd.com>> wrote:
changeset 9abf6a7c14ab in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=9abf6a7c14ab
description:
syscall: Add readlink to x86 with special case /proc/self/exe

This patch implements the correct behavior.

diffstat:

 src/arch/x86/linux/process.cc |   6 +++---
 src/sim/syscall_emul.cc   |  31 ++-
 2 files changed, 29 insertions(+), 8 deletions(-)

diffs (80 lines):

diff -r 255ebb0b32b4 -r 9abf6a7c14ab src/arch/x86/linux/process.cc
--- a/src/arch/x86/linux/process.cc Mon Jul 20 09:15:18 2015 -0500
+++ b/src/arch/x86/linux/process.cc Mon Jul 20 09:15:18 2015 -0500
@@ -485,7 +485,7 @@
 /* 264 */ SyscallDesc("renameat", unimplementedFunc),
 /* 265 */ SyscallDesc("linkat", unimplementedFunc),
 /* 266 */ SyscallDesc("sy

Re: [gem5-dev] changeset in gem5: syscall: Add readlink to x86 with special cas...

[Gutierrez, Anthony]

Using readlink() on /proc/self/exe would return the path to the gem5 binary 
previously, as opposed to the binary running inside of gem5. We noticed this 
because some of our codes used readlink() this way to figure out their paths.

If any codes use readlink() in this way, they need the correct path, and not 
gem5’s path. This isn’t non-determinism, the runs will always be the same given 
the binaries are in the same path. I’m not sure how this can be solved other 
than to say we won’t allow codes to use readlink() this way.

From: Joel Hestness [mailto:jthestn...@gmail.com]
Sent: Wednesday, September 09, 2015 10:32 AM
To: gem5 Developer List; Hashe, David; Che, Shuai; Gutierrez, Anthony
Subject: Re: [gem5-dev] changeset in gem5: syscall: Add readlink to x86 with 
special cas...

Hey David, Shuai, and Tony,

  It appears that this patch can introduce simulator non-determinism due to the 
use of Process::progName(). Basically, if benchmark paths are changed (e.g. 
running on a different system), then the string copy operations in the 
"/proc/self/exe" codepath can create strings of different lengths. As a result, 
readlink can return different values depending on the progName() and cause the 
simulated benchmark to behave differently. This is problematic when trying to 
replicate sims for regressions or debugging.

  It looks like this patch aims to address changes in GLIBC, which now uses 
readlink to find the binary before handling environment variables (in 
_dl_non_dynamic_init<http://osxr.org/glibc/source/elf/dl-support.c#0312>). That 
said, I'm not clear how this patch is supposed to fix problems or how we can 
avoid the nondeterminism it introduces. Can you guys elaborate on how this 
change is intended to work (e.g. what is the use case you were aiming for)?

  Thank you,
  Joel



On Sat, Aug 1, 2015 at 11:07 AM, David Hashe 
mailto:david.ha...@amd.com>> wrote:
changeset 9abf6a7c14ab in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=9abf6a7c14ab
description:
syscall: Add readlink to x86 with special case /proc/self/exe

This patch implements the correct behavior.

diffstat:

 src/arch/x86/linux/process.cc |   6 +++---
 src/sim/syscall_emul.cc   |  31 ++-
 2 files changed, 29 insertions(+), 8 deletions(-)

diffs (80 lines):

diff -r 255ebb0b32b4 -r 9abf6a7c14ab src/arch/x86/linux/process.cc
--- a/src/arch/x86/linux/process.cc Mon Jul 20 09:15:18 2015 -0500
+++ b/src/arch/x86/linux/process.cc Mon Jul 20 09:15:18 2015 -0500
@@ -485,7 +485,7 @@
 /* 264 */ SyscallDesc("renameat", unimplementedFunc),
 /* 265 */ SyscallDesc("linkat", unimplementedFunc),
 /* 266 */ SyscallDesc("symlinkat", unimplementedFunc),
-/* 267 */ SyscallDesc("readlinkat", unimplementedFunc),
+/* 267 */ SyscallDesc("readlinkat", readlinkFunc),
 /* 268 */ SyscallDesc("fchmodat", unimplementedFunc),
 /* 269 */ SyscallDesc("faccessat", unimplementedFunc),
 /* 270 */ SyscallDesc("pselect6", unimplementedFunc),
@@ -626,7 +626,7 @@
 /*  82 */ SyscallDesc("select", unimplementedFunc),
 /*  83 */ SyscallDesc("symlink", unimplementedFunc),
 /*  84 */ SyscallDesc("oldlstat", unimplementedFunc),
-/*  85 */ SyscallDesc("readlink", unimplementedFunc),
+/*  85 */ SyscallDesc("readlink", readlinkFunc),
 /*  86 */ SyscallDesc("uselib", unimplementedFunc),
 /*  87 */ SyscallDesc("swapon", unimplementedFunc),
 /*  88 */ SyscallDesc("reboot", unimplementedFunc),
@@ -846,7 +846,7 @@
 /* 302 */ SyscallDesc("renameat", unimplementedFunc),
 /* 303 */ SyscallDesc("linkat", unimplementedFunc),
 /* 304 */ SyscallDesc("symlinkat", unimplementedFunc),
-/* 305 */ SyscallDesc("readlinkat", unimplementedFunc),
+/* 305 */ SyscallDesc("readlinkat", readlinkFunc),
 /* 306 */ SyscallDesc("fchmodat", unimplementedFunc),
 /* 307 */ SyscallDesc("faccessat", unimplementedFunc),
 /* 308 */ SyscallDesc("pselect6", unimplementedFunc),
diff -r 255ebb0b32b4 -r 9abf6a7c14ab src/sim/syscall_emul.cc
--- a/src/sim/syscall_emul.cc   Mon Jul 20 09:15:18 2015 -0500
+++ b/src/sim/syscall_emul.cc   Mon Jul 20 09:15:18 2015 -0500
@@ -365,12 +365,10 @@
 }
 strncpy((char *)buf.bufferPtr(), cwd.c_str(), size);
 result = cwd.length();
-}
-else {
+} else {
 if (getcwd((char *)buf.bufferPtr(), size) != NULL) {
 result = strlen((char *)buf.bufferPtr());
-}
-else {
+} else {
 result = -1;
 }
 }
@@ -405,7 +403,30 @@

 BufferArg buf(bufPtr, bufsiz);

-int result = readlink(path.c_str(), (char *)buf.bufferPtr(), bufsiz);
+int result = -1;
+if (p

Re: [gem5-dev] including reviewboard URL in commit message?

[Gutierrez, Anthony]

I like that idea. Or at least the review number, for brevity's sake.

-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Steve Reinhardt
Sent: Friday, September 04, 2015 10:32 AM
To: gem5 Developer List
Subject: [gem5-dev] including reviewboard URL in commit message?

Hi everyone,

Just a thought: should we require commit messages to include the URL of the 
corresponding reviewboard posting?  I think that would be useful in tying the 
discussion to the commit.  Apologies if someone suggested this before and I 
missed it.

Steve
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3014: ruby: set: reimplement using std::bitset

[Gutierrez, Anthony]

I see. So it needs the bits in the set to identify which controllers to send 
to, and it can’t just send to all controllers? That is, the on-chip doesn’t 
have a list of all known controllers that it could use to identify where the 
messages should be sent?

From: Nilay Vaish [mailto:nore...@gem5.org] On Behalf Of Nilay Vaish
Sent: Thursday, September 03, 2015 1:56 PM
To: Nilay Vaish; Gutierrez, Anthony; Default; Jieming Yin
Subject: Re: Review Request 3014: ruby: set: reimplement using std::bitset

This is an automatically generated e-mail. To reply, visit: 
http://reviews.gem5.org/r/3014/



On August 17th, 2015, 9:37 p.m. UTC, Jieming Yin wrote:
src/mem/ruby/common/NetDest.cc<http://reviews.gem5.org/r/3014/diff/1/?file=48812#file48812line113>
 (Diff revision 1)


NetDest::getAllDest()

113


int id = MachineType_base_number((MachineType)i) + j;

113


int id = MachineType_base_number((MachineType)i) + j;


m_bits[i].getSize() returns NUMBER_BITS_PER_SET, which is 64 for all machine 
types. In case of broadcast, all bits are set in m_bits. Will it cause problem 
if the number of actual components is smaller than NUMBER_BITS_PER_SET? 
Perhapse in class Set, add a size parameter is a better idea to prevent such 
situation.

On August 31st, 2015, 2:59 p.m. UTC, Nilay Vaish wrote:

I have added back the m_nSize variable.

On September 3rd, 2015, 6:05 p.m. UTC, Tony Gutierrez wrote:

Maybe I'm missing something here, but why is m_nSize necessary for broadcast? 
It seemed to me that broadcast() only looks to see if all bits for the set are 
set, and doesn't determine how many to components to broadcast to. So it seems 
fine to me to have the logic of broadcast() be such that it will be considered 
a broadcast if all bits are set, and not a broadcast otherwise, the fact that 
there are extra bits set doesn't seem to matter.

On Thu, 3 Sep 2015, Tony Gutierrez wrote:



Maybe I'm missing something here, but why is m_nSize necessary for broadcast? 
It seemed to me that broadcast() only looks to see if all



Because of the way broadcast is implemented by the on-chip network.



bits for the set are set, and doesn't determine how many to components to 
broadcast to. So it seems fine to me to have the logic of broadcast() be such 
that it will be considered a broadcast if all bits are set, and not a broadcast 
otherwise, the fact that there are extra bits set doesn't seem to matter.



The on-chip will try to send the broadcast message to controllers corresponding

to bits that are set.  Hence, if there is no size variable to determine the 
maximum

number of bits in use, then messages will be sent to non-existent controllers.


- Nilay


On August 31st, 2015, 2:58 p.m. UTC, Nilay Vaish wrote:
Review request for Default.
By Nilay Vaish.

Updated Aug. 31, 2015, 2:58 p.m.
Repository: gem5
Description

Changeset 11077:0dfa7e7d62d0

---

ruby: set: reimplement using std::bitset

The current Set data structure is slow and therefore is being reimplemented

using std::bitset. A maximum limit of 64 is being set on the number of

controllers of each type.  This means that for simulating a system with more

controllers of a given type, one would need to change the value of the variable

NUMBER_BITS_PER_SET


Diffs

  *   src/mem/ruby/common/Set.hh (969113566d50)
  *   src/mem/ruby/common/Set.cc (969113566d50)
  *   src/mem/ruby/common/NetDest.hh (969113566d50)
  *   src/mem/ruby/common/SConscript (969113566d50)

View Diff<http://reviews.gem5.org/r/3014/diff/>


___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 2965: rename System.{hh, cc} to RubySystem.{hh, cc}

[Gutierrez, Anthony]

We can do either hg mv, or hg rm and hg add. What is preferred?

From: Nilay Vaish [mailto:nore...@gem5.org] On Behalf Of Nilay Vaish
Sent: Thursday, September 03, 2015 1:51 PM
To: Nilay Vaish; Gutierrez, Anthony; Hashe, David; Default
Subject: Re: Review Request 2965: rename System.{hh,cc} to RubySystem.{hh,cc}

This is an automatically generated e-mail. To reply, visit: 
http://reviews.gem5.org/r/2965/



On September 3rd, 2015, 6:36 p.m. UTC, Tony Gutierrez wrote:

Are they comments on this? We'd like to ship this soon.

Has hg mv been used to move those two files?


- Nilay


On July 13th, 2015, 7 p.m. UTC, David Hashe wrote:
Review request for Default.
By David Hashe.

Updated July 13, 2015, 7 p.m.
Repository: gem5
Description

Changeset 10923:8bdfe8dd9c2b

---

rename System.{hh,cc} to RubySystem.{hh,cc}



The eventual aim of this change is to pass RubySystem pointers through to 
objects generated from the SLICC protocol code.



Because some of these objects need to dereference their RubySystem pointers, 
they need access to the System.hh header file.



In src/mem/ruby/SConscript, the MakeInclude function creates single-line header 
files in the build directory that do nothing except include the corresponding 
header file from the source tree.



However, SLICC also generates a list of header files from its symbol table, and 
writes it to mem/protocol/Types.hh in the build directory. This code assumes 
that the header file name is the same as the class name.



The end result of this is the many of the generated slicc files try to include 
RubySystem.hh, when the file they really need is System.hh. The path of least 
resistence is just to rename System.hh to RubySystem.hh.


Diffs

  *   src/mem/ruby/system/RubySystem.cc (PRE-CREATION)
  *   src/mem/slicc/symbols/StateMachine.py 
(5ee72f4b293152dd0c75ab402a49696d6903e604)
  *   src/mem/ruby/system/System.cc (5ee72f4b293152dd0c75ab402a49696d6903e604)
  *   src/mem/ruby/system/System.hh (5ee72f4b293152dd0c75ab402a49696d6903e604)
  *   src/mem/ruby/system/Sequencer.cc 
(5ee72f4b293152dd0c75ab402a49696d6903e604)
  *   src/mem/ruby/system/SConscript (5ee72f4b293152dd0c75ab402a49696d6903e604)
  *   src/mem/ruby/system/RubySystem.py 
(5ee72f4b293152dd0c75ab402a49696d6903e604)
  *   src/mem/ruby/structures/CacheMemory.cc 
(5ee72f4b293152dd0c75ab402a49696d6903e604)
  *   src/mem/ruby/structures/BankedArray.cc 
(5ee72f4b293152dd0c75ab402a49696d6903e604)
  *   src/mem/ruby/structures/BankedArray.hh 
(5ee72f4b293152dd0c75ab402a49696d6903e604)
  *   src/mem/ruby/structures/DirectoryMemory.cc 
(5ee72f4b293152dd0c75ab402a49696d6903e604)
  *   src/mem/ruby/structures/Prefetcher.hh 
(5ee72f4b293152dd0c75ab402a49696d6903e604)
  *   src/mem/ruby/system/RubySystem.hh (PRE-CREATION)
  *   src/mem/ruby/system/RubyPort.hh (5ee72f4b293152dd0c75ab402a49696d6903e604)
  *   src/mem/ruby/system/DMASequencer.cc 
(5ee72f4b293152dd0c75ab402a49696d6903e604)
  *   src/mem/ruby/system/DMASequencer.hh 
(5ee72f4b293152dd0c75ab402a49696d6903e604)
  *   src/mem/ruby/system/CacheRecorder.cc 
(5ee72f4b293152dd0c75ab402a49696d6903e604)
  *   src/mem/ruby/structures/WireBuffer.cc 
(5ee72f4b293152dd0c75ab402a49696d6903e604)
  *   src/mem/ruby/structures/TimerTable.cc 
(5ee72f4b293152dd0c75ab402a49696d6903e604)
  *   src/mem/ruby/structures/RubyMemoryControl.cc 
(5ee72f4b293152dd0c75ab402a49696d6903e604)
  *   src/mem/ruby/structures/RubyMemoryControl.hh 
(5ee72f4b293152dd0c75ab402a49696d6903e604)
  *   src/mem/ruby/structures/Prefetcher.cc 
(5ee72f4b293152dd0c75ab402a49696d6903e604)
  *   src/mem/slicc/symbols/Type.py (5ee72f4b293152dd0c75ab402a49696d6903e604)
  *   src/mem/ruby/slicc_interface/AbstractController.cc 
(5ee72f4b293152dd0c75ab402a49696d6903e604)
  *   src/mem/ruby/network/simple/Throttle.cc 
(5ee72f4b293152dd0c75ab402a49696d6903e604)
  *   src/mem/ruby/network/simple/Throttle.hh 
(5ee72f4b293152dd0c75ab402a49696d6903e604)
  *   src/mem/ruby/network/simple/SimpleNetwork.cc 
(5ee72f4b293152dd0c75ab402a49696d6903e604)
  *   src/mem/ruby/network/garnet/flexible-pipeline/GarnetNetwork.cc 
(5ee72f4b293152dd0c75ab402a49696d6903e604)
  *   src/mem/ruby/network/garnet/fixed-pipeline/OutVcState_d.cc 
(5ee72f4b293152dd0c75ab402a49696d6903e604)
  *   src/mem/ruby/network/garnet/fixed-pipeline/GarnetNetwork_d.cc 
(5ee72f4b293152dd0c75ab402a49696d6903e604)
  *   src/mem/ruby/network/Network.cc (5ee72f4b293152dd0c75ab402a49696d6903e604)
  *   src/mem/ruby/network/MessageBuffer.cc 
(5ee72f4b293152dd0c75ab402a49696d6903e604)
  *   src/mem/ruby/filters/NonCountingBloomFilter.cc 
(5ee72f4b293152dd0c75ab402a49696d6903e604)
  *   src/mem/ruby/filters/MultiGrainBloomFilter.cc 
(5ee72f4b293152dd0c75ab402a49696d6903e604)
  *   src/mem/ruby/filters/LSB_CountingBloomFilter.cc 
(5ee72f4b293152dd0c75ab402a49696d6903e604)
  *   src/mem/ruby/filters/BulkBloomFilter.cc 
(5ee72f4b293152dd0c75ab402a49696d6903e604)
  *   src/mem/ruby/filters/BlockBloomFilt

Re: [gem5-dev] changeset in gem5: mem: Remove extraneous acquire/release flags ...

[Gutierrez, Anthony]

Thanks, Andreas. I'll post another patch for review.


From: gem5-dev [gem5-dev-boun...@gem5.org] on behalf of Andreas Hansson 
[andreas.hans...@arm.com]
Sent: Thursday, August 27, 2015 2:18 AM
To: gem5 Developer List; gem5-...@m5sim.org
Subject: Re: [gem5-dev] changeset in gem5: mem: Remove extraneous 
acquire/release flags ...

Hi Tony,

It is definitely not an ideal solution, and it will break compatibility
with all existing traces (trust me, this is a _big_ deal). If we stick to
the uint32_t and can shift these flags to the ‘end’ of the list it is
probably ok as a stop-gap solution. Please ensure it stops at the two
flags though, and I would suggest also adding a @todo and comment
regarding this not being final.

Andreas

On 27/08/2015 10:09, "gem5-dev on behalf of Gutierrez, Anthony"
 wrote:

>Hi Andreas,
>
>While we agree there should be a better long term solution, this is what
>we have now and what our GPU model - that we plan to release publicly
>very soon - relies upon. If we added the flags to currently unused bits
>in the flags and kept the flag size to 32 bits, would you mind if we
>added these fields to the request flags until a better solution can be
>agreed upon?
>
>-Tony
>
>From: gem5-dev [gem5-dev-boun...@gem5.org] on behalf of Andreas Hansson
>[andreas.hans...@arm.com]
>Sent: Thursday, August 27, 2015 12:58 AM
>To: gem5 Developer List; gem5-...@m5sim.org
>Subject: Re: [gem5-dev] changeset in gem5: mem: Remove extraneous
>acquire/release flags ...
>
>Hi Brad,
>
>I do not think we should check this patch in as is (hence the removal).
>There needs to be a sensible design around the use of flags, and I remain
>to be convinced that adding a request flag for every ‘action' is not the
>way to go. There is already a long discussion thread on the dev list.
>Perhaps the request needs something like an Action or Command.
>
>Andreas
>
>
>On 26/08/2015 23:40, "gem5-dev on behalf of Beckmann, Brad"
> wrote:
>
>>Andreas,
>>
>>It just came to my attention that this changeset removes acquire and
>>release attributes from both the packet and the request.  The comment on
>>the checkin seemed to indicate that it was only extraneous flags, but
>>these are required to make our GPU code work.  We would prefer at least
>>having the flags part of the request.
>>
>>Can we please check this patch in and keep it in the repo?
>>
>>Thanks,
>>
>>Brad
>>
>>
>>-Original Message-
>>From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Andreas
>>Hansson
>>Sent: Friday, August 07, 2015 1:56 AM
>>To: gem5-...@m5sim.org
>>Subject: [gem5-dev] changeset in gem5: mem: Remove extraneous
>>acquire/release flags ...
>>
>>changeset ba91725c8f6b in /z/repo/gem5
>>details: http://repo.gem5.org/gem5?cmd=changeset;node=ba91725c8f6b
>>description:
>>   mem: Remove extraneous acquire/release flags and attributes
>>
>>   This patch removes the extraneous flags and attributes from the
>>   request and packet, and simply leaves the new commands. The change
>>   introduced when adding acquire/release breaks all compatibility
>>with
>>   existing traces, and there is really no need for any new flags and
>>   attributes. The commands should be sufficient.
>>
>>   This patch fixes packet tracing (urgent), and also removes the
>>   unnecessary complexity.
>>
>>diffstat:
>>
>> src/mem/packet.cc  |   8 
>> src/mem/packet.hh  |   6 --
>> src/mem/request.hh |  53
>>+
>> 3 files changed, 25 insertions(+), 42 deletions(-)
>>
>>diffs (181 lines):
>>
>>diff -r 4413195267fd -r ba91725c8f6b src/mem/packet.cc
>>--- a/src/mem/packet.ccWed Aug 05 10:27:11 2015 +0100
>>+++ b/src/mem/packet.ccFri Aug 07 04:55:38 2015 -0400
>>@@ -166,13 +166,13 @@
>> /* IntResp -- for interrupts */
>> { SET2(IsWrite, IsResponse), InvalidCmd, "MessageResp" },
>> /* ReleaseReq -- for release synchronization */
>>-{ SET3(IsRelease, IsRequest, NeedsResponse), ReleaseResp,
>>"ReleaseReq" },
>>+{ SET2(IsRequest, NeedsResponse), ReleaseResp, "ReleaseReq" },
>> /* ReleaseResp -- for release synchronization */
>>-{ SET2(IsRelease, IsResponse), InvalidCmd, "ReleaseResp" },
>>+{ SET1(IsResponse), InvalidCmd, "ReleaseResp" },
>> /* AcquireReq -- for release synchronization */
>>-{ SET3(IsAcquir

Re: [gem5-dev] changeset in gem5: mem: Remove extraneous acquire/release flags ...

[Gutierrez, Anthony]

Hi Andreas,

While we agree there should be a better long term solution, this is what we 
have now and what our GPU model - that we plan to release publicly very soon - 
relies upon. If we added the flags to currently unused bits in the flags and 
kept the flag size to 32 bits, would you mind if we added these fields to the 
request flags until a better solution can be agreed upon?

-Tony

From: gem5-dev [gem5-dev-boun...@gem5.org] on behalf of Andreas Hansson 
[andreas.hans...@arm.com]
Sent: Thursday, August 27, 2015 12:58 AM
To: gem5 Developer List; gem5-...@m5sim.org
Subject: Re: [gem5-dev] changeset in gem5: mem: Remove extraneous 
acquire/release flags ...

Hi Brad,

I do not think we should check this patch in as is (hence the removal).
There needs to be a sensible design around the use of flags, and I remain
to be convinced that adding a request flag for every ‘action' is not the
way to go. There is already a long discussion thread on the dev list.
Perhaps the request needs something like an Action or Command.

Andreas


On 26/08/2015 23:40, "gem5-dev on behalf of Beckmann, Brad"
 wrote:

>Andreas,
>
>It just came to my attention that this changeset removes acquire and
>release attributes from both the packet and the request.  The comment on
>the checkin seemed to indicate that it was only extraneous flags, but
>these are required to make our GPU code work.  We would prefer at least
>having the flags part of the request.
>
>Can we please check this patch in and keep it in the repo?
>
>Thanks,
>
>Brad
>
>
>-Original Message-
>From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Andreas
>Hansson
>Sent: Friday, August 07, 2015 1:56 AM
>To: gem5-...@m5sim.org
>Subject: [gem5-dev] changeset in gem5: mem: Remove extraneous
>acquire/release flags ...
>
>changeset ba91725c8f6b in /z/repo/gem5
>details: http://repo.gem5.org/gem5?cmd=changeset;node=ba91725c8f6b
>description:
>   mem: Remove extraneous acquire/release flags and attributes
>
>   This patch removes the extraneous flags and attributes from the
>   request and packet, and simply leaves the new commands. The change
>   introduced when adding acquire/release breaks all compatibility with
>   existing traces, and there is really no need for any new flags and
>   attributes. The commands should be sufficient.
>
>   This patch fixes packet tracing (urgent), and also removes the
>   unnecessary complexity.
>
>diffstat:
>
> src/mem/packet.cc  |   8 
> src/mem/packet.hh  |   6 --
> src/mem/request.hh |  53
>+
> 3 files changed, 25 insertions(+), 42 deletions(-)
>
>diffs (181 lines):
>
>diff -r 4413195267fd -r ba91725c8f6b src/mem/packet.cc
>--- a/src/mem/packet.ccWed Aug 05 10:27:11 2015 +0100
>+++ b/src/mem/packet.ccFri Aug 07 04:55:38 2015 -0400
>@@ -166,13 +166,13 @@
> /* IntResp -- for interrupts */
> { SET2(IsWrite, IsResponse), InvalidCmd, "MessageResp" },
> /* ReleaseReq -- for release synchronization */
>-{ SET3(IsRelease, IsRequest, NeedsResponse), ReleaseResp,
>"ReleaseReq" },
>+{ SET2(IsRequest, NeedsResponse), ReleaseResp, "ReleaseReq" },
> /* ReleaseResp -- for release synchronization */
>-{ SET2(IsRelease, IsResponse), InvalidCmd, "ReleaseResp" },
>+{ SET1(IsResponse), InvalidCmd, "ReleaseResp" },
> /* AcquireReq -- for release synchronization */
>-{ SET3(IsAcquire, IsRequest, NeedsResponse), AcquireResp,
>"AcquireReq" },
>+{ SET2(IsRequest, NeedsResponse), AcquireResp, "AcquireReq" },
> /* AcquireResp -- for release synchronization */
>-{ SET3(IsAcquire, IsResponse, NeedsResponse), InvalidCmd,
>"AcquireResp" },
>+{ SET2(IsResponse, NeedsResponse), InvalidCmd, "AcquireResp" },
> /* InvalidDestError  -- packet dest field invalid */
> { SET2(IsResponse, IsError), InvalidCmd, "InvalidDestError" },
> /* BadAddressError   -- memory address invalid */
>diff -r 4413195267fd -r ba91725c8f6b src/mem/packet.hh
>--- a/src/mem/packet.hhWed Aug 05 10:27:11 2015 +0100
>+++ b/src/mem/packet.hhFri Aug 07 04:55:38 2015 -0400
>@@ -151,8 +151,6 @@
> IsError,//!< Error response
> IsPrint,//!< Print state matching address (for debugging)
> IsFlush,//!< Flush the address from caches
>-IsAcquire,  //!< Acquire operation
>-IsRelease,  //!< Release operation
> NUM_COMMAND_ATTRIBUTES
> };
>
>@@ -209,8 +207,6 @@
> bool isError() const{ return testCmdAttrib(IsError); }
> bool isPrint() const{ return testCmdAttrib(IsPrint); }
> bool isFlush() const{ return testCmdAttrib(IsFlush); }
>-bool isAcquire() const  { return testCmdAttrib(IsAcquire); }
>-bool isRelease() const  { return testCmdAttrib(IsRelease); }
>
> const Command
> responseCommand() const
>@@ -492,8 +488,6 @@
> bool

Re: [gem5-dev] extending request with more attributes

[Gutierrez, Anthony]

Thanks for this clarification, Andreas. We were mostly confused by the flags, 
cmd, and attributes because - as you pointed out - there seems to be a lot of 
overlap with no clear division between the three objects. I think this patch is 
going in a good direction.

For our particular case it seems we have a few options. Use regular read/write 
commands but have special flags denoting them as ACQUIRE/RELEASE (2). Or we 
could have multiple commands for the each of the sync/serializing ops with 
attributes denoting them as IsSynchornizing or IsSerializing etc (4,5).

Are those suitable options? Are there other options?

-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Andreas Hansson
Sent: Thursday, August 06, 2015 4:43 PM
To: gem5 Developer List
Subject: Re: [gem5-dev] extending request with more attributes

Hi Marc (et al),

Have a look at http://reviews.gem5.org/r/3004/ for addressing (5) in my 
previous mail.

Andreas

On 06/08/2015 10:41, "gem5-dev on behalf of Andreas Hansson"
 wrote:

>Hi Marc,
>
>I would suggest the following (again, this is up for discussion):
>
>1. Request flags should the kind of properties that we would have 
>associated with page-table entries. I am thinking memory attributes 
>like uncacheable, strictly ordered, secure, etc.
>
>2. Request flags could also be used to distinguish packets of specific 
>types, where ‘normal’ packet commands like read/write are used, but we 
>want to be able to single out what the ‘reason’ is. Prefetch, PT walks, 
>Fetch, etc.
>
>3. We should try and sort out the current use of CLEAR_LL, LOCKED_RMW, 
>LLSC, MEM_SWAP, and MEM_SWAP_COND. In my view these should not really 
>be request flags, because we have specific packets to represent these 
>actions. Also, most of these are ArchSpecific and should go in the 
>ArchSpecific flags. Perhaps we just need to figure out a better way to 
>do this.
>
>4. Packet attributes should be common attributes shared by multiple 
>families of packet commands. Good examples are ‘NeedsResponse’, 
>‘IsRead’, ‘NeedsExclusive’ etc.
>
>5. Packet attributes should not be introduced if they only apply to a 
>single request/response. Thus, I think we should remove IsSWPrefetch 
>and IsHWPrefetch as an attribute.
>
>Does this align with your view of the world?
>
>Andreas
>
>
>
>On 05/08/2015 22:30, "gem5-dev on behalf of Marc Orr"
> wrote:
>
>>In response to reviews http://reviews.gem5.org/r/2821/ and 
>>http://reviews.gem5.org/r/3003/.
>>
>>I was going to look at addressing this today for AMD. I'm not 
>>extremely familiar with the organization of the request flags, packet 
>>commands, packet attributes, and packet flags. That said, I was under 
>>the impression that the request is supposed to capture information 
>>that exist at the instruction level. To me, acquire and release are at 
>>the instruction level (not a spurious command between two memory 
>>controllers like  flush command).
>>
>>Also, the 32 bits that we have to work with in the request seems 
>>rather small. Especially, when you consider that it needs to capture 
>>all of the possible attributes for a memory request across all of the 
>>different ISAs...
>>
>>How would armv8 ldra and strl instructions convey to the cache 
>>hierarchy acquire/release attributes from the instruction (if it were 
>>necessary)?
>>
>>Thanks,
>>Marc
>>___
>>gem5-dev mailing list
>>gem5-dev@gem5.org
>>http://m5sim.org/mailman/listinfo/gem5-dev
>
>
>-- IMPORTANT NOTICE: The contents of this email and any attachments are 
>confidential and may also be privileged. If you are not the intended 
>recipient, please notify the sender immediately and do not disclose the 
>contents to any other person, use it for any purpose, or store or copy 
>the information in any medium.  Thank you.
>
>ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, 
>Registered in England & Wales, Company No:  2557590 ARM Holdings plc, 
>Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in 
>England & Wales, Company No:  2548782 
>___
>gem5-dev mailing list
>gem5-dev@gem5.org
>http://m5sim.org/mailman/listinfo/gem5-dev


-- IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium.  Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered 
in England & Wales, Company No:  2557590 ARM Holdings plc, Registered office 
110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company 
No:  2548782 ___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
__

Re: [gem5-dev] changeset in gem5: mem: add request types for acquire and release

[Gutierrez, Anthony]

We will take a look at these issues and try to rework our code to keep the flag 
size 32b.

-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Andreas Hansson
Sent: Saturday, August 01, 2015 11:20 AM
To: gem5 Developer List; gem5-...@m5sim.org
Subject: Re: [gem5-dev] changeset in gem5: mem: add request types for acquire 
and release

Besides performance issues and unnecessary complexity, one key issue with the 
flags/commands are modified is that it breaks backwards compatibility with any 
existing packet trace.

Andreas

On 01/08/2015 19:17, "gem5-dev on behalf of Andreas Hansson"
 wrote:

>Hi all,
>
>This patch has outstanding issues that were _not_ addressed. In 
>particular, it unnecessarily increases the flag size, and adds both 
>flags and request types when only one is needed. I suggest we either 
>revert it or fix the outstanding issues.
>
>Thanks,
>
>Andreas
>
>On 01/08/2015 17:51, "gem5-dev on behalf of David Hashe"
> wrote:
>
>>changeset eba4e93665fc in /z/repo/gem5
>>details: http://repo.gem5.org/gem5?cmd=changeset;node=eba4e93665fc
>>description:
>>   mem: add request types for acquire and release
>>
>>   Add support for acquire and release requests.  These 
>>synchronization operations
>>   are commonly supported by several modern instruction sets.
>>
>>diffstat:
>>
>> src/mem/packet.cc |  10 +-
>> src/mem/packet.hh |  12 +++-
>> src/mem/protocol/RubySlicc_Exports.sm |   3 +
>> src/mem/request.hh|  54
>>+-
>> 4 files changed, 56 insertions(+), 23 deletions(-)
>>
>>diffs (228 lines):
>>
>>diff -r bbdf1177f250 -r eba4e93665fc src/mem/packet.cc
>>--- a/src/mem/packet.ccMon Jul 20 09:15:18 2015 -0500
>>+++ b/src/mem/packet.ccMon Jul 20 09:15:18 2015 -0500
>>@@ -12,7 +12,7 @@
>>  * modified or unmodified, in source code or in binary form.
>>  *
>>  * Copyright (c) 2006 The Regents of The University of Michigan
>>- * Copyright (c) 2010 Advanced Micro Devices, Inc.
>>+ * Copyright (c) 2010,2015 Advanced Micro Devices, Inc.
>>  * All rights reserved.
>>  *
>>  * Redistribution and use in source and binary forms, with or without 
>>@@ -165,6 +165,14 @@
>> MessageResp, "MessageReq" },
>> /* IntResp -- for interrupts */
>> { SET2(IsWrite, IsResponse), InvalidCmd, "MessageResp" },
>>+/* ReleaseReq -- for release synchronization */
>>+{ SET3(IsRelease, IsRequest, NeedsResponse), ReleaseResp,
>>"ReleaseReq" },
>>+/* ReleaseResp -- for release synchronization */
>>+{ SET2(IsRelease, IsResponse), InvalidCmd, "ReleaseResp" },
>>+/* AcquireReq -- for release synchronization */
>>+{ SET3(IsAcquire, IsRequest, NeedsResponse), AcquireResp,
>>"AcquireReq" },
>>+/* AcquireResp -- for release synchronization */
>>+{ SET3(IsAcquire, IsResponse, NeedsResponse), InvalidCmd,
>>"AcquireResp" },
>> /* InvalidDestError  -- packet dest field invalid */
>> { SET2(IsResponse, IsError), InvalidCmd, "InvalidDestError" },
>> /* BadAddressError   -- memory address invalid */
>>diff -r bbdf1177f250 -r eba4e93665fc src/mem/packet.hh
>>--- a/src/mem/packet.hhMon Jul 20 09:15:18 2015 -0500
>>+++ b/src/mem/packet.hhMon Jul 20 09:15:18 2015 -0500
>>@@ -12,7 +12,7 @@
>>  * modified or unmodified, in source code or in binary form.
>>  *
>>  * Copyright (c) 2006 The Regents of The University of Michigan
>>- * Copyright (c) 2010 Advanced Micro Devices, Inc.
>>+ * Copyright (c) 2010,2015 Advanced Micro Devices, Inc.
>>  * All rights reserved.
>>  *
>>  * Redistribution and use in source and binary forms, with or without 
>>@@ -110,6 +110,10 @@
>> SwapResp,
>> MessageReq,
>> MessageResp,
>>+ReleaseReq,
>>+ReleaseResp,
>>+AcquireReq,
>>+AcquireResp,
>> // Error responses
>> // @TODO these should be classified as responses rather than
>> // requests; coding them as requests initially for backwards 
>>@@ -147,6 +151,8 @@
>> IsError,//!< Error response
>> IsPrint,//!< Print state matching address (for
>>debugging)
>> IsFlush,//!< Flush the address from caches
>>+IsAcquire,  //!< Acquire operation
>>+IsRelease,  //!< Release operation
>> NUM_COMMAND_ATTRIBUTES
>> };
>>
>>@@ -203,6 +209,8 @@
>> bool isError() const{ return testCmdAttrib(IsError); }
>> bool isPrint() const{ return testCmdAttrib(IsPrint); }
>> bool isFlush() const{ return testCmdAttrib(IsFlush); }
>>+bool isAcquire() const  { return testCmdAttrib(IsAcquire); }
>>+bool isRelease() const  { return testCmdAttrib(IsRelease); }
>>
>> const Command
>> responseCommand() const
>>@@ -484,6 +492,8 @@
>> bool isError() const { return cmd.isError(); }
>> bool isPrint() const { return cmd.isPrint(); }
>>  

Re: [gem5-dev] pd-gem5: simulating a parallel/distributed system on multiple physical hosts

[Gutierrez, Anthony]

 previous comment. The most important part of
>>multi/pd-gem5
>extension is ensuring accurate and deterministic simulation.
>
>
>> >
>> >* Amount of changes
>> >
>> >pd-gem5 introduce different modes in etherlink just to provide 
>> >accurate timing for each component in the network subsystem (NIC, 
>> >link, switch)
>>as
>> >well as capability of modeling different network topologies (mesh,
>>ring,
>> >fat tree, etc). To enable a simple functionality, like what 
>> >multi-gem5 provides, the amount of changes in gem5 can be limited to 
>> >time-stamping packets and providing synchronization through python 
>> >scripts. However,
>> >multi-gem5 re-implements functionalists that are already in gem5.
>>
>> This argument holds only if both implementations are correct (robust).
>>It
>> still seems to me that pd-gem5 does not provide correctness for the  
>>synchronization/checkpointing parts.
>>
>> Again, please read my first comment for correctness of pd-gem5.
>
>
>> >
>> >* Integrating with gem5 mainstream:
>> >
>> >pd-gem5 launch script is written in python which is suited for
>>integration
>> >with gem5 python scripts. However multi-gem5 uses bash script. Also,
>>all
>> >source files in pd-gem5 are already parts of gem5 mainstream. 
>> >However
>> >multi-gem5 has tcp_server.cc/hh that is a standalone process and 
>> >cannot
>> be
>> >part of gem5.
>>
>> The multi-gem5 launch script is simply enough to rely only on the 
>>shell. It  can obviously be easily re-written in python if that added 
>>any value.
>>The
>> tcp_server component is only a utility (like the "m5" utility that is 
>>also  part of gem5).
>>
>> The thing is that it's more likely that users want to add some
>functionality to the run-script of multi/pd-gem5. E.g. pd-gem5 
>run-script supports launching simulations using a simulation pool 
>management software ( http://research.cs.wisc.edu/htcondor/). Using 
>python enables users to easily add these kind of supports.
>
>
>>
>> Cheers,
>> - Gabor
>>
>>
>> >On Fri, Jun 26, 2015 at 8:40 PM, Curtis Dunham 
>> >
>> >wrote:
>> >
>> >>Hello everyone,
>> >>We have taken a look at how pd-gem5 compares with multi-gem5.  
>> >>While intending to deliver the same functionality, there are some 
>> >>crucial differences:
>> >>
>> >>*  Synchronization.
>> >>
>> >>    pd-gem5 implements this in Python (not a problem in itself; 
>> >>aesthetically
>> >>this is nice, but...).  The issue is that pd-gem5's data 
>> >>packets
>>and
>> >>barrier messages travel over different sockets.  Since pd-gem5
>>could
>> >>see
>> >>data packets passing synchronization barriers, it could create an
>> >>inconsistent checkpoint.
>> >>
>> >>multi-gem5's synchronization is implemented in C++ using sync
>>events,
>> >>but
>> >>more importantly, the messages queue up in the same stream and 
>> >>so cannot
>> >>have the issue just described.  (Event ordering is often 
>> >>crucial
>>in
>> >>snapshot protocols.) Therefore we feel that multi-gem5 is a 
>> >>more robust
>> >>solution in this respect.
>> >>
>> >>*  Packet handling.
>> >>
>> >>pd-gem5 uses EtherTap for data packets but changed the polling 
>> >>mechanism
>> >>to go through the main event queue.  Since this rate is 
>> >>actually linked
>> >>with simulator progress, it cannot guarantee that the packets 
>> >>are serviced
>> >>at regular intervals of real time.  This can lead to packets 
>> >>queueing up
>> >>which would contribute to the synchronization issues mentioned
>>above.
>> >>
>> >>multi-gem5 uses plain sockets with separate receive threads and 
>> >>so does not
>> >>have this issue.
>> >>
>> >>* Checkpoint accuracy.
>> >>
>> >>   A user would like to have a checkpoint at precisely the time the
>> >>   'm5 checkpoint' operation is executed so as to not miss any of the
>> >>   area of interest in his application.
>> >>
>> >>   pd-gem5 requires th

Re: [gem5-dev] pd-gem5: simulating a parallel/distributed system on multiple physical hosts

[Gutierrez, Anthony]

Would it make sense for me to ship the EtherSwitch patch first, since it has 
utility on its own, and then we can decide which of the "multi-gem5" approaches 
is best, or if it's some combination of both?

The only reason I never shipped it was because Steve raised an issue that I 
didn't have a good alternative for, and didn't have the time to look into one 
at that time.

From: gem5-dev [gem5-dev-boun...@gem5.org] on behalf of Mohammad Alian 
[al...@wisc.edu]
Sent: Wednesday, June 24, 2015 12:43 PM
To: gem5 Developer List
Subject: Re: [gem5-dev] pd-gem5: simulating a parallel/distributed system on 
multiple physical hosts

Hi Andreas,

Thanks for the comment.
I think the checkpointing support in both works is the same. Here is how
checkpointing support is implemented in pd-gem5:

Whenever one of gem5 processes encounter an m5-checkpoint pseudo
instruction, it will send a “recv-ckpt” signal to the
“barrier” process. Then the “barrier” process sends a “take-ckpt” signal to
all the simulated nodes
(including the node that encountered m5-checkpoint) at the end of the
current simulation quantum. On the reception of
“take-ckpt” signal, gem5 processes start dumping check-points. This makes
each simulated node dump a checkpoint
at the same simulated time point while ensuring there is no in-flight
packets.

I believe this is the same as multi-gem5 patch approach for checkpoint
support (based on the commit message of http://reviews.gem5.org/r/2865/).
Also, we have tested our mechanism with several benchmarks and it works. As
Steve suggested, I'll look into Curtis's patch and try to review it as
well.
But as Nilay also mentioned earlier, there are some codes missing in
Curtis's patch. I prefer to first run multi-gem5 before starting to review
it.

Thank you,
Mohammad

On Wed, Jun 24, 2015 at 7:25 AM, Andreas Hansson 
wrote:

> Hi Steve,
>
> Apologies for the confusion. We are on the same page. My point is that we
> cannot simply take a little bit of patch A and a little bit of patch B.
> This change involves a lot of code, and we need to approach this in a
> structured fashion. My proposal is to do it bottom up, and start by
> getting the basic support in place. Since http://reviews.gem5.org/r/2826/
> has already been on the review board for a few months, I am merely
> suggesting that the it would be a good start to relate the newly posted
> patches to what is already there.
>
> Andreas
>
>
>
> On 24/06/2015 13:11, "gem5-dev on behalf of Steve Reinhardt"
>  wrote:
>
> >Hi Andreas,
> >
> >I'm a little confused by your email---you say you're fundamentally opposed
> >to looking at both patches and picking the best features, then you point
> >out that the patches Curtis posted have the feature of better
> >checkpointing
> >support so we should pick that :).
> >
> >Obviously we can't just pick patch A from Mohammad's set and patch B from
> >Curtis's set and expect them to work together, but I think that having
> >both
> >sets of patches available and comparing and contrasting the two
> >implementations should enable us to get to a single implementation that's
> >the best of both. Someone will have to make the effort of integrating the
> >better ideas from one set into the other set to create a new unified set
> >of
> >patches; (or maybe we commit one set and then integrate the best of the
> >other set as patches on top of that), but the first step is to identify
> >what "the best of both" is.  Having Mohammad look at Curtis's patches, and
> >Curtis (or someone else from ARM) closely examine Mohammad's patches would
> >be a great start.  I intend to review them both, though unfortunately my
> >time has been scarce lately---I'm hoping to squeeze that in later this
> >week.
> >
> >Once we've had a few people look at both, we can discuss the pros and cons
> >of each, then discuss the strategy for getting the best features in.  So
> >far I've heard that Mohammad's patches have a better network model but the
> >ARM patches have better checkpointing support; that seems like a good
> >start.
> >
> >Steve
> >
> >On Wed, Jun 24, 2015 at 12:26 AM Andreas Hansson  >
> >wrote:
> >
> >> Hi all,
> >>
> >> Great work. However, I fundamentally do not believe in the approach of
> >> ‘letting reviewers pick the best features’. There is no way we would
> >>ever
> >> get something working out if it. We need to get _one_ working solution
> >> here, and figure out how to best get there. I would propose to do it
> >> bottom up, starting with the basic multi-simulator instance support,
> >> checkpointing support, and then move on to the network between the
> >> simulator instances.
> >>
> >> Thus, I propose we go with the low-level plumbing and checkpoint support
> >> from what Curtis has posted. I believe proper checkpointing support to
> >>be
> >> the most challenging, and from what I can tell this is far more limited
> >>in
> >> what you just posted Mohammad. Could you perhaps review Curtis patches
> >

Re: [gem5-dev] changeset in gem5: cpu: o3: replace issueLatency with bool pipel...

[Gutierrez, Anthony]

Nilay,

Sorry I didn't review this before it went out, but would you mind reverting 
this patch? I do believe that issueLat should remain Cycles be allowed to be 
set to any value. One can certainly imagine a FU where you have a latency of X, 
and yet a throughput of 1 op / Y cycles, where Y != X or 1.

Perhaps a patch that instead adds a comment to explain the semantics of 
issueLat - as opposed to removing it - would suffice?

-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Nilay Vaish
Sent: Wednesday, April 29, 2015 8:40 PM
To: gem5-...@m5sim.org
Subject: [gem5-dev] changeset in gem5: cpu: o3: replace issueLatency with bool 
pipel...

changeset dac26eb4cb64 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=dac26eb4cb64
description:
cpu: o3: replace issueLatency with bool pipelined

Currently, each op class has a parameter issueLat that denotes the 
cycles after
which another op of the same class can be issued.  As of now, this 
latency can
either be one cycle (fully pipelined) or same as execution latency of 
the op
(not at all pipelined).  The fact that issueLat is a parameter of type 
Cycles
makes one believe that it can be set to any value.  To avoid the 
confusion, the
parameter is being renamed as 'pipelined' with type boolean.  If set to 
true,
the op would execute in a fully pipelined fashion. Otherwise, it would 
execute
in an unpipelined fashion.

diffstat:

 configs/common/O3_ARM_v7a.py  |  10 +-
 src/cpu/FuncUnit.py   |   3 ++-
 src/cpu/func_unit.cc  |  14 +++---
 src/cpu/func_unit.hh  |  10 +-
 src/cpu/o3/FuncUnitConfig.py  |   9 -
 src/cpu/o3/fu_pool.cc |   8 
 src/cpu/o3/fu_pool.hh |   8 
 src/cpu/o3/inst_queue_impl.hh |   5 ++---
 8 files changed, 33 insertions(+), 34 deletions(-)

diffs (244 lines):

diff -r b9410e821c41 -r dac26eb4cb64 configs/common/O3_ARM_v7a.py
--- a/configs/common/O3_ARM_v7a.py  Wed Apr 29 22:35:22 2015 -0500
+++ b/configs/common/O3_ARM_v7a.py  Wed Apr 29 22:35:22 2015 -0500
@@ -36,9 +36,9 @@
 
 # Complex ALU instructions have a variable latencies  class 
O3_ARM_v7a_Complex_Int(FUDesc):
-opList = [ OpDesc(opClass='IntMult', opLat=3, issueLat=1),
-   OpDesc(opClass='IntDiv', opLat=12, issueLat=12),
-   OpDesc(opClass='IprAccess', opLat=3, issueLat=1) ]
+opList = [ OpDesc(opClass='IntMult', opLat=3, pipelined=True),
+   OpDesc(opClass='IntDiv', opLat=12, pipelined=False),
+   OpDesc(opClass='IprAccess', opLat=3, pipelined=True) ]
 count = 1
 
 
@@ -67,8 +67,8 @@
OpDesc(opClass='FloatAdd', opLat=5),
OpDesc(opClass='FloatCmp', opLat=5),
OpDesc(opClass='FloatCvt', opLat=5),
-   OpDesc(opClass='FloatDiv', opLat=9, issueLat=9),
-   OpDesc(opClass='FloatSqrt', opLat=33, issueLat=33),
+   OpDesc(opClass='FloatDiv', opLat=9, pipelined=False),
+   OpDesc(opClass='FloatSqrt', opLat=33, pipelined=False),
OpDesc(opClass='FloatMult', opLat=4) ]
 count = 2
 
diff -r b9410e821c41 -r dac26eb4cb64 src/cpu/FuncUnit.py
--- a/src/cpu/FuncUnit.py   Wed Apr 29 22:35:22 2015 -0500
+++ b/src/cpu/FuncUnit.py   Wed Apr 29 22:35:22 2015 -0500
@@ -54,9 +54,10 @@
 class OpDesc(SimObject):
 type = 'OpDesc'
 cxx_header = "cpu/func_unit.hh"
-issueLat = Param.Cycles(1, "cycles until another can be issued")
 opClass = Param.OpClass("type of operation")
 opLat = Param.Cycles(1, "cycles until result is available")
+pipelined = Param.Bool(True, "set to true when the functional unit for"
+"this op is fully pipelined. False means not pipelined at 
+ all.")
 
 class FUDesc(SimObject):
 type = 'FUDesc'
diff -r b9410e821c41 -r dac26eb4cb64 src/cpu/func_unit.cc
--- a/src/cpu/func_unit.cc  Wed Apr 29 22:35:22 2015 -0500
+++ b/src/cpu/func_unit.cc  Wed Apr 29 22:35:22 2015 -0500
@@ -52,7 +52,7 @@
 
 for (int i = 0; i < Num_OpClasses; ++i) {
 opLatencies[i] = fu.opLatencies[i];
-issueLatencies[i] = fu.issueLatencies[i];
+pipelined[i] = fu.pipelined[i];
 }
 
 capabilityList = fu.capabilityList; @@ -60,15 +60,15 @@
 
 
 void
-FuncUnit::addCapability(OpClass cap, unsigned oplat, unsigned issuelat)
+FuncUnit::addCapability(OpClass cap, unsigned oplat, bool pipeline)
 {
-if (issuelat == 0 || oplat == 0)
+if (oplat == 0)
 panic("FuncUnit:  you don't really want a zero-cycle latency do you?");
 
 capabilityList.set(cap);
 
 opLatencies[cap] = oplat;
-issueLatencies[cap] = issuelat;
+pipelined[cap] = pipeline;
 }
 
 bool
@@ -89,10 +89,10 @@
 return opLatencies[cap];
 }
 
-unsigned
-FuncUnit::issueLatency(OpClass capability)
+bool
+FuncUnit::isPipelined(OpClass capability)
 {
-return issueLatencies