[gem5-dev] Re: Request for comments/reviews: Multiple Ruby protocols in a single binary

[Beckmann, Brad via gem5-dev]

[AMD Official Use Only]

Hi Jason,

This is a huge undertaking.  I'm very impressed that you got this the work.  
Congratulations!

Your email covers many important aspects of the change, but one item missing is 
the motivation for the change.  Is it primarily compilation simplicity?  Now 
one can build gem5 once and use that binary to run multiple different protocols 
at different times?  If so, can you speak to the compilation speedup of 
compiling all protocols at once versus compiling each one individually.  Also 
does this change allow us to add more tests to check-ins because we don't have 
to spend as much time building a bunch of individual binaries?  Some quantified 
data could really help motivate the downstream work involved to consume this 
change.

Thanks!

Brad




From: Jason Lowe-Power via gem5-dev 
Sent: Thursday, March 31, 2022 9:42 AM
To: gem5 Developer List 
Cc: Jason Lowe-Power 
Subject: [gem5-dev] Request for comments/reviews: Multiple Ruby protocols in a 
single binary

[CAUTION: External Email]
Hi all,

For as long as gem5 has been gem5, you have had to build a different gem5 
binary if you want to use a different Ruby protocol. Making it possible to 
build multiple protocols has been on the roadmap for a long time (at least as 
long as I've been involved with the project).

I'm excited to say that we've been able to do this (finally), and we have a set 
of changesets on gerrit for review/comments feedback.

There are a couple of todo items before it's merged, and a couple of 
user-facing changes that we could not find a way to make fully backwards 
compatible. More on this below.

Let me know what you think, and let me know if there are any questions! I'm 
excited to see this get in for gem5-22.0.

Changes: 
https://gem5-review.googlesource.com/q/topic:all-ruby-protocols

Non-backwards compatible changes:
Previously each SLICC protocol used the same names for the same machine time. 
E.g., MI_example has an `L1Cache_Controller` and MSI has an 
`L1Cache_Controller`. These names were automatically generated from the 
MachineType (L1Cache) + "_Controller". Now, since we want to be able to compile 
these two protocols at the same time, we need to make sure there are no 
(python) name clashes. So, these have been renamed to have the protocol name 
prepended onto the machine name (e.g., `MI_example_L1Cache_Controller`).

For most people using Ruby, we can provide backwards compatibility. If you 
simply instantiate the `L1Cache_Controller` in python, we can provide a new 
factory function that does the "right" thing. However, if you inherit from 
`L1Cache_Controller` to specialize the controller, this won't work.

The user-facing change is if you have any local ruby protocol configuration 
files which use inheritance with the controllers, you will have to update the 
controller classes to use the name of the protocol prepended on the controller 
name.

We have updated all of the configurations that are in the gem5 repo. You will 
see warnings if you use the old backwards-compatible names (including with 
Ruby.py).

The only other user-facing change (I think, reviewers, please point out if I'm 
wrong), is that in places that `buildEnv["PROTOCOL"]` was used to check the 
protocol that was built, you will now need to use `getRubyProtocol` (also 
available in `m5.defines`). However, we are currently supporting backwards 
compatibility here, but there will be no warning when we drop backwards 
compatibility (I expect this to be in a couple of releases).

To do items
- Correctly integrate this with scons (and the new kconfig). See 
https://gem5-review.googlesource.com/c/public/gem5/+/58443
 for a WIP that needs to be updated.
- Update the website. Assuming there are no major flaws in our implementation, 
we will update the website soon (before the changes are committed). The main 
updates are the two user-facing changes described above, but I expect some 
updates to how Ruby/SLICC works as well.
- Add another commit that checks if the protocol is in the list of built 
protocols instead of a single protocol. I'm holding off on this one until item 
#1 is complete. This will also include 

Re: [gem5-dev] Updating Contribution.md review guidelines. Feedback appreciated.

[Beckmann, Brad]

Thanks Bobby.

Most of this looks good to me, except can we extend the "no response period" in 
1) from 48 hours to 2 weeks?  Abandoning a patchset is a big step, so we should 
make sure the contributor is unreachable beforehand.

Brad


-Original Message-
From: gem5-dev  On Behalf Of Bobby Bruce
Sent: Friday, October 4, 2019 11:21 AM
To: gem5 Developer List 
Subject: [gem5-dev] Updating Contribution.md review guidelines. Feedback 
appreciated.

[CAUTION: External Email]

Dear all,

I'm currently in the process of updating CONTRIBUTING.md with some  Gerrit Code 
Review guidelines (please see my WIP change here: 
https://gem5-review.googlesource.com/c/public/gem5/+/21419 ). My reason for 
doing this is finding out no one really knows the procedure for addressing some 
common problems in Gerrit. I think having some written-down guidelines, 
understood by both reviewers and contributors, will help us overcome this. I 
outline here the three  problems I've observed in how we currently work with 
Gerrit and how these guidelines help:

1) It doesn't seem like we have a good policy for handling old, active changes. 
It's all too common for a change to be uploaded, a few rounds of patchsets to 
be submitted, then the original contributor disappears. It seems like, at 
present, no one knows how to handle this in a consistent way. To address this 
I've added a guideline that after a month of inactivity from the original 
contributor, reviewers can reach out and ping contributors on a change. If 
after 48 hours of no response (or confirmation the contributor is no longer 
interested), reviewers can take ownership or abandon the change. Whether to 
abandon or take ownership will need to be decided on a case-by-case basis. I 
hope with this policy we can reduce the number of open changes in Gerrit over 
time.

2) I've observed that sometimes a change, for whatever reason, enters a "Ready 
to Submit" state and stays there for a while. I found a couple of instances of 
old "Ready to Submit" changes (i.e., >1 month). It's odd and as time goes on, 
the chances of this "Ready to Submit" change incurring a merge conflict 
increases. I've therefore added a guideline that the original contributor of a 
change has 48 hours to give a final sign-off and submit once the change reaches 
a "Ready to Submit" state. After this period a reviewer may do so on the 
original contributors behalf.

3) Some have noted to me that they are unsure what the procedure is for 
submitting a patchset to a change in which they are not the owner (commonly 
occurring in the "It'll take more time for me to explain what to do than just 
do it myself" scenario). I think it's best-practice to have the original 
contributor own the change but others may contribute patchsets after asking 
permission or for minor changes such as typos or formatting issues (i.e., 
completely inoffensive changes). There is some embedded flexibility here but, 
by and large, i think communication and consent is key.

Outside of this, the remaining guidelines are basically common-sense reminders 
(i.e., be polite, please address every piece of feedback a given, etc.), which 
should help remind new contributors on how to manage the process.

Please feel free to let me know what you think of these changes and if they 
could be improved upon (I'm also open to adding more guidelines if anyone has 
noticed some room for improvement).

Kind regards,
Bobby
___
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] Ruby Sequencer starving O3 core?

[Beckmann, Brad]

Hi Timothy,

As Jason said, this is a known issue.  In fact we tried to fix it many years 
ago in the public tree but we had difficulty getting the patch approved and 
eventually discarded our effort.

http://reviews.gem5.org/r/2276/

We still have this patch applied to our internal tree and it works quite well.  
Another key change along these same lines is splitting the store address 
request from the store data request.  Unfortunately that patch has never made 
it out of our internal tree and we need to find someone within AMD to maintain 
it before we can push it publicly. 

There are a few things to keep in mind when thinking about how to improve the 
CPU/GPU to Ruby interface.  The Sequencer and Coalescer implement protocol 
agnostic logic, such as address coalescing and request tracking.  We could move 
this logic into the L1 cache controllers, but that would require duplicating 
that work in each controller and further complicating the already complicated 
state transitions.  Furthermore, the generated protocol state machines only 
operate on cache-line aligned addresses, but all gem5 CPU and GPU core models 
send byte-aligned address to their ports.  Thus the Sequencer and Coalescer are 
in charge of managing the byte to cache-line address conversion.

I hope this helps and let us know how you want to proceed.

Thanks,

Brad



-Original Message-
From: gem5-dev  On Behalf Of Jason Lowe-Power
Sent: Tuesday, September 24, 2019 8:11 AM
To: gem5 Developer List 
Subject: Re: [gem5-dev] Ruby Sequencer starving O3 core?

[CAUTION: External Email]

Hi Timothy,

The short answer is that this is a quasi-known issue. The interface between the 
core and Ruby needs to be improved. (It's on the roadmap! Though, no one is 
actively working on it.)

I could be wrong myself, but I believe you're correct that Ruby cannot handle 
multiple loads to the same cache block. I believe in previous incarnations of 
the simulator that the coalescing into cache blocks happened in the LSQ. 
However, the classic caches assume this happens in the cache creating a 
mis-match between Ruby and the classic caches.

I'm not sure what the best fix for this is. Unless it's a small change, we 
should probably discuss the design with Brad and Tony before putting 
significant effort into coding.

Cheers,
Jason

On Sun, Sep 22, 2019 at 3:20 PM Timothy Hayes  wrote:

> I'm experimenting with various O3 configurations combined with Ruby's 
> MESI_Three_Level memory subsystem. I notice that it's very challenging 
> to provide the core with more memory bandwidth. For typical/realistic 
> O3/Ruby/memory parameters, a single core struggles to achieve 3000 
> MB/s in STREAM. If I max out all the parameters of the O3 core, Ruby, 
> the NoC and provide a lot of memory bandwidth, STREAM just about 
> reaches 6000 MB/s. I believe this should be much higher. I've found 
> one possible explanation for this behaviour.
>
> The Ruby Sequencer receives memory requests from the core via the 
> function Sequencer::insertRequest(PacketPtr pkt, RubyRequestType 
> request_type). This function determine whether there are requests to 
> the same cache line and--if there are--returns without enqueing the 
> memory request. This also happens with load requests in which there is 
> already an outstanding load request to the same cache line.
>
> RequestTable::value_type default_entry(line_addr, (SequencerRequest*) 
> NULL); pair r  = 
> m_readRequestTable.insert(default_entry);
>
> if (r.second) {
> /* snip */
> } else {
> // There is an outstanding read request for the cache line
> m_load_waiting_on_load++;
> return RequestStatus_Aliased;
> }
>
> This eventually returns to the LSQ which interprets the Aliased 
> RequestStatus as the cache controller being blocked.
>
> bool LSQUnit::trySendPacket(bool isLoad, PacketPtr data_pkt) {
> if (!lsq->cacheBlocked() &&
> lsq->cachePortAvailable(isLoad)) {
> if (!dcachePort->sendTimingReq(data_pkt)) {
> ret = false;
> cache_got_blocked = true;
> }
>  }
>  if (cache_got_blocked) {
>  lsq->cacheBlocked(true);
> ++lsqCacheBlocked;
>  }
> }
>
> If the code is generating many load requests to contigious memory, 
> e.g. in STREAM, won't the cache get blocked extremely frequently? 
> Would this explain why it's so difficult to get the core to consume more 
> bandwidth?
>
> I'm happy to go ahead and fix/improve this, but I wanted to check 
> first that I'm not missing something--can Ruby handle multiple 
> outstanding loads to the same cache line without blocking the cache?
>
>
> --
>
> Timothy Hayes
>
> Senior Research Engineer
>
> Arm Research
>
> Phone: +44-1223405170
>
> timothy.ha...@arm.com
>
>
> ​
>
>
> 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 

Re: [gem5-dev] cc registers

[Beckmann, Brad]

+Yasuko

Hi Gabe,

Yes, I remember that change.  That was actually performed by a former AMD co-op 
Binh Pham (who was advised by Yasuko).  Bihn did a lot of great work digging 
into the O3 model finding various performance bugs.  Most of his fixes where 
added back in 2015, but some of them never got checked in (e.g. splitting store 
access requests from store data requests).

CC register renaming was a big performance issue with x86.  By mapping all CC 
regs to one physical renamed register added a lot of false dependencies.  It is 
very important that they stay separate.

I hope that helps.

Brad



-Original Message-
From: gem5-dev  On Behalf Of Jason Lowe-Power
Sent: Tuesday, October 16, 2018 3:10 PM
To: gem5 Developer List 
Subject: Re: [gem5-dev] cc registers

Hey Gabe,

I don't know if this helps, but I remember a lot of problems with register 
renaming and CC registers ~6ish years ago. IIRC, there's a separate pool of 
physical registers for the CC registers so that they do not limit the renaming 
of "normal" registers.

There were probably some discussions on the former reviewboard about this.
But again, it was so long ago that I don't remember the exact context. In fact, 
this might not have anything to do with why they are special registers.

Cheers,
Jason

On Mon, Oct 15, 2018 at 8:57 PM Gabe Black  wrote:

> Hey folks. I think I'm missing some context from when I was away from gem5.
> Does anyone know why there's a separate register file defined 
> explicitly for condition code registers? Why is having them as integer 
> registers not sufficient?
>
> Also as a general point, it's bad form to have "generic" features like 
> this which are hidden behind #ifdefs and #defines and only implemented 
> for one or two ISAs. Another example of this is a feature in MIPS 
> which it uses to read registers of other threads and which is only 
> available in that ISA. If the primitives available for ISAs aren't 
> sufficient lets fix that, not add on ISA specific extensions which are 
> unused or incompatible with most of the ISAs and hidden behind flags.
>
> 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

Re: [gem5-dev] scons question

[Beckmann, Brad]

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

Re: [gem5-dev] Compilation error for gem5 after statfs change

[Beckmann, Brad]

Just because someone modified the wiki a few years ago and said we support 
OpenBSD and OSX doesn't mean much.  As your second bullet points out, there are 
several scenarios the wiki says gem5 supports that lack any testing 
infrastructure to back up those statements.

I believe Brandon wants to continue to work with you on fixing your "supported" 
scenarios.  However, it seems more fair if those of you who use OSX or OpenBSD 
test out Brandon's fixes rather than asking him to set up an entire virtual 
machine environment that attempts to mirror your environment.

Brad



-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Andreas Hansson
Sent: Thursday, February 2, 2017 1:35 AM
To: gem5 Developer List <gem5-dev@gem5.org>; Potter, Brandon 
<brandon.pot...@amd.com>
Subject: Re: [gem5-dev] Compilation error for gem5 after statfs change

Hi Brad,

A few things worth noting here:

- OSX/MacOs has been working fine for the last 4+ years, and is mentioned on 
gem5.org as a supported OS (so is OpenBSD btw). I know there are users that 
rely on it, and I would suggest we try and keep it working.

- Clearly there is a problem in that we have plenty ‘supported’ builds (OSX, 
without Python, with SystemC, etc) that are not tested or even built as part of 
the regressions. Once we make the move to CI-land some of this should be easier 
to address.

- For now I would suggest we simply try our best to not break things, and for 
the few patches related to syscall emulation it would be great if you can check 
on a OSX/BSD host before pushing (alternatively co-ordinate with someone else 
to check). For the breakage that already snuck in, there are plenty people 
willing to help, but they will likely need Brandon’s help to get things 
resolved.

Thanks again to everyone, especially Brandon, for all help.

Andreas

On 28/01/2017, 20:21, "gem5-dev on behalf of Beckmann, Brad"
<gem5-dev-boun...@gem5.org on behalf of brad.beckm...@amd.com> wrote:

>I must chime in here.
>
>Brandon is putting in an heroic effort here and you keep asking him to 
>do more and more.  I'm really concerned with the precedent being set.  
>I do not believe there has ever been a consensus that gem5 supports any 
>OS other than Linux.  Once we have a common public regression tester 
>infrastructure that allows us to test multiple OSes, then we can 
>officially add other OSes if people add the tests to do so.  However 
>until that happens, can someone who actually cares about these 
>non-standard environments run these tests?
>
>Brad
>
>
>
>-Original Message-
>From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Jason 
>Lowe-Power
>Sent: Thursday, January 26, 2017 3:55 PM
>To: gem5 Developer List <gem5-dev@gem5.org>; Potter, Brandon 
><brandon.pot...@amd.com>
>Subject: Re: [gem5-dev] Compilation error for gem5 after statfs change
>
>Hi Brandon,
>
>BTW, here's a Travis-CI config file that will run tests on GCC and 
>Clang on both Mac and Linux hosts. We can add many more parameters for 
>different versions of compilers, etc., but this is something that 
>should allow you to test changes on more than just your current platform.
>
>If you have a github mirror, every time you push to it, Travis-CI kicks 
>off
>4 builds (for the matrix of OS and compiler).
>
>https://github.com/powerjg/gem5-ci-test/blob/master/.travis.yml
>
>It would be great if you could take a look at this, Brandon.
>
>Thanks,
>Jason
>
>On Thu, Jan 26, 2017 at 4:47 AM Andreas Hansson 
><andreas.hans...@arm.com>
>wrote:
>
>> Hi all,
>>
>> While I agree about the end goal (test every commit on every 
>> platform) I would suggest we go about this one step at a time. The 
>> likelihood of breakage is only high for anything related to syscall 
>> emulation, so it really only affects a small part of the developer 
>> community. Agreed?
>>
>> With that in mind I think we can prevent 99% of the issues if syscall  
>>emulation patches are built on a BSD system with clang. I would be  
>>wrong, but I would think this is a very good filter, with a fairly low  
>>cost and effort of deployment. Virtualbox + some flavour of BSD would 
>>do it.
>>
>> Andreas
>>
>> On 25/01/2017, 23:18, "gem5-dev on behalf of Jason Lowe-Power"
>> <gem5-dev-boun...@gem5.org on behalf of ja...@lowepower.com> wrote:
>>
>> >Yeah, it's a major problem that we say that we support macOS and 
>> >others when we allow commits that break builds on these other OSes.
>> >
>> >If we are going to say that we have support for OSes other than 
>> >Linux, we need to at least verify gem5 builds on these OSes, 
>> >

Re: [gem5-dev] Compilation error for gem5 after statfs change

[Beckmann, Brad]

I must chime in here.

Brandon is putting in an heroic effort here and you keep asking him to do more 
and more.  I'm really concerned with the precedent being set.  I do not believe 
there has ever been a consensus that gem5 supports any OS other than Linux.  
Once we have a common public regression tester infrastructure that allows us to 
test multiple OSes, then we can officially add other OSes if people add the 
tests to do so.  However until that happens, can someone who actually cares 
about these non-standard environments run these tests?

Brad



-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Jason Lowe-Power
Sent: Thursday, January 26, 2017 3:55 PM
To: gem5 Developer List ; Potter, Brandon 

Subject: Re: [gem5-dev] Compilation error for gem5 after statfs change

Hi Brandon,

BTW, here's a Travis-CI config file that will run tests on GCC and Clang on 
both Mac and Linux hosts. We can add many more parameters for different 
versions of compilers, etc., but this is something that should allow you to 
test changes on more than just your current platform.

If you have a github mirror, every time you push to it, Travis-CI kicks off
4 builds (for the matrix of OS and compiler).

https://github.com/powerjg/gem5-ci-test/blob/master/.travis.yml

It would be great if you could take a look at this, Brandon.

Thanks,
Jason

On Thu, Jan 26, 2017 at 4:47 AM Andreas Hansson 
wrote:

> Hi all,
>
> While I agree about the end goal (test every commit on every platform) 
> I would suggest we go about this one step at a time. The likelihood of 
> breakage is only high for anything related to syscall emulation, so it 
> really only affects a small part of the developer community. Agreed?
>
> With that in mind I think we can prevent 99% of the issues if syscall 
> emulation patches are built on a BSD system with clang. I would be 
> wrong, but I would think this is a very good filter, with a fairly low 
> cost and effort of deployment. Virtualbox + some flavour of BSD would do it.
>
> Andreas
>
> On 25/01/2017, 23:18, "gem5-dev on behalf of Jason Lowe-Power"
>  wrote:
>
> >Yeah, it's a major problem that we say that we support macOS and 
> >others when we allow commits that break builds on these other OSes.
> >
> >If we are going to say that we have support for OSes other than 
> >Linux, we need to at least verify gem5 builds on these OSes, 
> >preferably before accepting a commit. I'm currently testing out the 
> >free Travis-CI service ( https://travis-ci.org/powerjg/gem5-ci-test). 
> >We could probably hook this up to our gem5 github page, if it works 
> >out.
> >
> >Another important point, though, is that we can't expect all 
> >committers to own multiple machines to test their changes on. We need 
> >something that will do pre-commit builds on all the platforms we 
> >claim to support.
> >
> >We're in the middle of moving the regression tests to a hosted 
> >jenkins instance. Hopefully this will solve some of these issues 
> >(though I don't think it will support multiple OS builds).
> >
> >Do others have any ideas on a long-term solution here?
> >
> >Cheers,
> >Jason
> >
> >On Tue, Jan 24, 2017 at 5:46 PM Bjoern A. Zeeb < 
> >bzeeb-li...@lists.zabbadoz.net> wrote:
> >
> >On 24 Jan 2017, at 22:08, Jason Lowe-Power wrote:
> >
> >> Hi Brandon,
> >>
> >> I think this is a "real" bug:
> >>
> >
> http://qa.gem5.org//1905/compiling-problem-gem5-mac-os-10-11-6-scons-b
> uild
> >-arm-gem5-opt
> >.
> >> I think there are a few more places that need an #ifdef NO_STATFS.
> >> Could
> >> you look into it and post a patch if there's a problem? If not, 
> >> please reply to the gem5 QA post and let them know.
> >
> >Can people try this one and probably get the #ifdefs right for NetBSD 
> >as well?  There are at least 3 different checks for that code;  if 
> >people don’t care about “style” I could get it right, but ..
> >
> >diff -r e47703369039 src/sim/syscall_emul.hh
> >--- a/src/sim/syscall_emul.hh   Fri Jan 20 14:12:58 2017 -0500
> >+++ b/src/sim/syscall_emul.hh   Tue Jan 24 23:45:04 2017 +
> >@@ -70,6 +70,8 @@
> >  #include 
> >  #if (NO_STATFS == 0)
> >  #include 
> >+#else
> >+#include 
> >  #endif
> >  #include 
> >  #include 
> >@@ -530,20 +532,25 @@
> >  {
> >  TypedBufferArg tgt(addr);
> >
> >+tgt->f_type = TheISA::htog(host->f_type);
> >  #if defined(__OpenBSD__) || defined(__APPLE__) || defined(__FreeBSD__)
> >-tgt->f_type = 0;
> >+tgt->f_bsize = TheISA::htog(host->f_iosize);
> >  #else
> >-tgt->f_type = TheISA::htog(host->f_type);
> >+tgt->f_bsize = TheISA::htog(host->f_bsize);
> >  #endif
> >-tgt->f_bsize = TheISA::htog(host->f_bsize);
> >  tgt->f_blocks = TheISA::htog(host->f_blocks);
> >  tgt->f_bfree = TheISA::htog(host->f_bfree);
> >  tgt->f_bavail = TheISA::htog(host->f_bavail);
> >  

Re: [gem5-dev] Fault handling issue

[Beckmann, Brad]

Hi Rodolfo,

I'm glad to hear you were able to solve your issue.  Just curious, did you find 
that the current evictionCallback interface was sufficient for your use case?

Brad



-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Rodolfo 
Guilherme Wottrich
Sent: Friday, August 19, 2016 10:46 AM
To: gem5 Developer List 
Subject: Re: [gem5-dev] Fault handling issue

For future reference: my problem was not that subsequent instructions would not 
squash. I missed out on the fact that the store queue's behaviour is 
asynchronous and although the instructions had been committed many cycles 
before, the requests would still be in the store queue to be consumed by the 
cache. It was only a matter of forcefully removing the stores for the LSQ and 
it worked.


---
Rodolfo Wottrich

On Mon, Aug 15, 2016 at 5:24 PM, Rodolfo Guilherme Wottrich < rgw...@gmail.com> 
wrote:

> Hi Fernando,
>
> Thank you for the suggestion. Yes, I have tried that, but the problem 
> is that no similar faults take happen, especially in SE mode.
> I wonder if it may be the case of some squashing function call that I 
> am missing.
>
> Does anybody have experience with squashing instructions in the commit 
> stage?
>
>
> ---
> Rodolfo Wottrich
>
> On Mon, Aug 8, 2016 at 10:08 AM, Fernando Endo 
> 
> wrote:
>
>> Hello,
>>
>> Probably I can't technically help you here, but have you considered 
>> observing the simulator behavior when similar faults happen? For 
>> example, simulate a program that access an invalid address and enable 
>> all related debug flags to track it (--debug-flags option).
>>
>> Hope it helps,
>>
>> --
>> Fernando A. Endo, Post-doc
>>
>> INRIA Rennes-Bretagne Atlantique
>> France
>>
>>
>> 2016-08-03 3:30 GMT+02:00 Rodolfo Guilherme Wottrich :
>>
>> > Hello,
>> >
>> > I would like to request some assistance if possible. For my PhD 
>> > work, I need to be able to trigger a CPU fault when a particular 
>> > condition in
>> the
>> > L1 cache controller is met. I am using an o3 x86 CPU and Ruby in SE
>> mode.
>> >
>> > I have come to a partial solution to the problem, based on a patch 
>> > I
>> found
>> > which dealt with a similar situation. That involves creating a new 
>> > Sequencer callback function that is used only at that specific
>> situation in
>> > the cache controller which triggers a sequence of actions that
>> eventually
>> > lead to a Fault object being instantiated in the LSQ and in the 
>> > commit stage of the pipeline.
>> >
>> > The problem is that although the Fault and its handling are "working"
>> > (control flow changes and registers are updated as they should),
>> subsequent
>> > requests still keep being received by the cache in the mandatory 
>> > queue
>> from
>> > the instructions following the offending one. Those instructions 
>> > should have been cancelled as in a branch misprediction and their 
>> > requests
>> should
>> > have been removed from the LSQ to avoid inconsistency.
>> >
>> > Can anybody think of why I am having such a problem/how can I solve it?
>> I
>> > can provide specifics once the discussion starts.
>> >
>> > Thank you in advance.
>> > Cheers,
>> >
>> > ---
>> > Rodolfo Wottrich
>> > ___
>> > 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] Let's retire some ISAs

[Beckmann, Brad]

As the name suggests, I think MI_example still provides an excellent simple 
example for those people getting started with Ruby.  I would like to see it 
maintained.

Brad


-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Steve Reinhardt
Sent: Wednesday, June 08, 2016 4:16 PM
To: gem5 Developer List <gem5-dev@gem5.org>
Subject: Re: [gem5-dev] Let's retire some ISAs

Brad, does that include MI_example?

Steve


On Wed, Jun 8, 2016 at 4:13 PM Beckmann, Brad <brad.beckm...@amd.com> wrote:

> I just want to chime in and say that we definitely want to continue to 
> test the same number of Ruby protocols as before.  Let test them with x86.
> I suspect that is the most common CPU ISA used with Ruby.
>
> Thanks,
>
> Brad
>
>
>
> -Original Message-
> From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Steve 
> Reinhardt
> Sent: Wednesday, June 08, 2016 4:01 PM
> To: gem5 Developer List <gem5-dev@gem5.org>
> Subject: Re: [gem5-dev] Let's retire some ISAs
>
> Yes, I could quibble with your model, but I agree, I don't think it's 
> worthwhile ;).  I do think we've already outlined a number of steps 
> (plus a couple others I thought of) that we could take immediately 
> that are (I
> believe) totally uncontroversial:
>
> 1. Let's prune a lot of the long regressions that don't add much 
> value, particularly for less-supported ISAs.  Concretely, getting rid 
> of all the long SE-mode ALPHA tests is pretty low-hanging fruit here.
> 2. Let's make sure the wiki is up-to-date on the level of support 
> provided for various ISAs.
> 3. Let's add warnings, ideally at both compile time and run time, 
> letting users know when they are using a less-supported ISA.
> 4. Let's make the default Ruby protocol something useful, so that we 
> can do basic testing of both classic and Ruby memory systems with a 
> single compile.
> 5. Let's only compile that one version of less-supported ISAs (read:
> ALPHA), instead of compiling it with four (!) different extra Ruby 
> protocols.  If we really want to test multiple Ruby protocols, we 
> might as well at least do it using a well-supported ISA.
> 6. Let's give it another few days, but unless someone responds to my 
> pleading EIO email from 6/3, let's go ahead and ditch EIO support.
>
> I suggest we go ahead and do the things we all agree on and see where 
> that leaves us before we debate about additional steps.
>
> Steve
>
> On Wed, Jun 8, 2016 at 3:20 PM Andreas Hansson 
> <andreas.hans...@arm.com>
> wrote:
>
> > Hi Steve,
> >
> > In short: If we want to put in effort X to achieve something, we end 
> > up having to put in 1.25 X (overhead times #ISAs), but it is only 
> > 1.05 X that is actually useful (due to low utility). The 3 months 
> > was merely me translating the wasted effort into a relatable number 
> > using the current months commit count.
> >
> > Again, let’s not obsess about the numbers. Let us instead focus on 
> > making the most of our efforts and decide what is needed and what is not.
> >
> > AndreasH
> >
> > On 08/06/2016, 23:05, "gem5-dev on behalf of Steve Reinhardt"
> > <gem5-dev-boun...@gem5.org on behalf of ste...@gmail.com> wrote:
> >
> > >Hi Andreas,
> > >
> > >I don't know that I want a whole spreadsheet, but it's not clear to 
> > >me how a 5% overhead turns into wasting 25% of our time (3 months 
> > >out
> of 12).
> > >Partly that may be because I'm not sure what an "incremental cost 
> > >of [...] 5% on average" means either.  Can you elaborate please?
> > >
> > >Thanks,
> > >
> > >Steve
> > >
> > >
> > >On Wed, Jun 8, 2016 at 2:20 PM Andreas Hansson 
> > ><andreas.hans...@arm.com>
> > >wrote:
> > >
> > >> Hi all,
> > >>
> > >> It is worth remembering that the argument about “low" effort 
> > >>needs to take  long-term usefulness into account. Yes, the 
> > >>incremental effort may seem  small per commit, but if the 
> > >>incremental cost per ISA is 5% on average,  and the likelihood of 
> > >>that effort being useful long term is 20%, then  after one year we 
> > >>have effectively wasted 3 months of gem5 contributions.
> > >> That is 90 commits.
> > >>
> > >> We can of course debate these numbers (let me know if you want 
> > >> the spreadsheet...), but let’s not fool ourselves. Keeping things 
> > >> around has noticeable implications on the overall progress.
> > >>
> 

Re: [gem5-dev] Let's retire some ISAs

[Beckmann, Brad]

I just want to chime in and say that we definitely want to continue to test the 
same number of Ruby protocols as before.  Let test them with x86.  I suspect 
that is the most common CPU ISA used with Ruby.

Thanks,

Brad



-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Steve Reinhardt
Sent: Wednesday, June 08, 2016 4:01 PM
To: gem5 Developer List 
Subject: Re: [gem5-dev] Let's retire some ISAs

Yes, I could quibble with your model, but I agree, I don't think it's 
worthwhile ;).  I do think we've already outlined a number of steps (plus a 
couple others I thought of) that we could take immediately that are (I
believe) totally uncontroversial:

1. Let's prune a lot of the long regressions that don't add much value, 
particularly for less-supported ISAs.  Concretely, getting rid of all the long 
SE-mode ALPHA tests is pretty low-hanging fruit here.
2. Let's make sure the wiki is up-to-date on the level of support provided for 
various ISAs.
3. Let's add warnings, ideally at both compile time and run time, letting users 
know when they are using a less-supported ISA.
4. Let's make the default Ruby protocol something useful, so that we can do 
basic testing of both classic and Ruby memory systems with a single compile.
5. Let's only compile that one version of less-supported ISAs (read:
ALPHA), instead of compiling it with four (!) different extra Ruby protocols.  
If we really want to test multiple Ruby protocols, we might as well at least do 
it using a well-supported ISA.
6. Let's give it another few days, but unless someone responds to my pleading 
EIO email from 6/3, let's go ahead and ditch EIO support.

I suggest we go ahead and do the things we all agree on and see where that 
leaves us before we debate about additional steps.

Steve

On Wed, Jun 8, 2016 at 3:20 PM Andreas Hansson 
wrote:

> Hi Steve,
>
> In short: If we want to put in effort X to achieve something, we end 
> up having to put in 1.25 X (overhead times #ISAs), but it is only 1.05 
> X that is actually useful (due to low utility). The 3 months was 
> merely me translating the wasted effort into a relatable number using 
> the current months commit count.
>
> Again, let’s not obsess about the numbers. Let us instead focus on 
> making the most of our efforts and decide what is needed and what is not.
>
> AndreasH
>
> On 08/06/2016, 23:05, "gem5-dev on behalf of Steve Reinhardt"
>  wrote:
>
> >Hi Andreas,
> >
> >I don't know that I want a whole spreadsheet, but it's not clear to 
> >me how a 5% overhead turns into wasting 25% of our time (3 months out of 12).
> >Partly that may be because I'm not sure what an "incremental cost of 
> >[...] 5% on average" means either.  Can you elaborate please?
> >
> >Thanks,
> >
> >Steve
> >
> >
> >On Wed, Jun 8, 2016 at 2:20 PM Andreas Hansson 
> >
> >wrote:
> >
> >> Hi all,
> >>
> >> It is worth remembering that the argument about “low" effort needs 
> >>to take  long-term usefulness into account. Yes, the incremental 
> >>effort may seem  small per commit, but if the incremental cost per 
> >>ISA is 5% on average,  and the likelihood of that effort being 
> >>useful long term is 20%, then  after one year we have effectively 
> >>wasted 3 months of gem5 contributions.
> >> That is 90 commits.
> >>
> >> We can of course debate these numbers (let me know if you want the 
> >> spreadsheet...), but let’s not fool ourselves. Keeping things 
> >> around has noticeable implications on the overall progress.
> >>
> >> AndreasH
> >>
> >>
> >> On 08/06/2016, 17:11, "gem5-dev on behalf of Steve Reinhardt"
> >>  wrote:
> >>
> >> >On Wed, Jun 8, 2016 at 8:12 AM Andreas Sandberg
> >> >> >
> >> >wrote:
> >> >
> >> >> >
> >> >> >Once the bar for reaching this point is raised by adding the 
> >> >> >steps
> >>of
> >> >> >determining that gem5 *used to* support the ISA of interest, 
> >> >> >finding
> >> >>and
> >> >> >extracting the old revision that still had that support in it, 
> >> >> >and
> >>very
> >> >> >likely needing to do who knows how much work to bring the ISA
> >>support
> >> >>back
> >> >> >in sync with the head of the repo before being able to 
> >> >> >reasonably
> >>make
> >> >> >further enhancements, then the likelihood of anyone crossing 
> >> >> >that threshold is going to be dramatically lowered.
> >> >>
> >> >> You raise a valid point. However, I don¹t completely agree with 
> >> >> your
> >>the
> >> >> conclusion.
> >> >>
> >> >
> >> >Hi Andreas, can you elaborate?  I don't see anything you're saying 
> >> >that disagrees with what I think I said.
> >> >
> >> >
> >> >> For complex work, say reworking register interfaces (e.g.,
> >>Nathanael¹s
> >> >> patch), modifying every single ISA adds a significant 
> >> >> development overhead.
> >> >
> >> >

Re: [gem5-dev] Let's retire some ISAs

[Beckmann, Brad]

Hi Andreas,

Though I work for a company that only produces ARM/x86-compatible processors 
and I do live in Redmond, WA :), I am firmly in the camp that we should not 
eliminate any ISAs.  The gem5 simulator is a tremendously valuable tool to the 
entire community, not just ARM and AMD.  We need to maintain whatever features 
we can to sustain and grow our user and developer base.  

As others have already pointed out, there is still significant industry support 
for MIPS, SPARC, and POWER.  Perhaps an argument could be made against ALPHA, 
but how hard is that ISA to maintain?  Also there is some historical 
significance to ALPHA, since it was the first ISA.  As Boris just pointed out, 
if anything, we should actively be encouraging someone to add RISC-V.  We only 
drive people away from the simulator when we discuss removing features.

Brad


-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of 
shinga...@labware.com
Sent: Monday, June 06, 2016 11:24 AM
To: gem5 Developer List 
Subject: Re: [gem5-dev] Let's retire some ISAs

Hi Andreas,

> POWER and MIPS.
> [...]
> They won't be missed.

This is certainly not so here in my project where POWER and MIPS are the 
primary available options, and dropping them would be pretty much equivalent to 
discontinuing GEM5 altogether.

What feels even more sad, is that I can see how the very presence of this 
discussion within the Overton window could be used by certain closed-source 
advocates to undermine our "community support" argument and thus try to weaken 
the position of not only our choice of GEM5 but some neighbouring open-source 
choices as well.

> users submitting patches for them

This one should easily exclude MIPS and POWER from candidates for phasing out, 
well at least I do submit MIPS and POWER patches which get merged into origin.

> Ecosystem: We should phase out ISAs that don't have compiler support.  
> Being able to run code isn't very useful if you can't compile code for 
> the platform.

True; and the above's implied connection to MIPS and/or POWER, sounds 
disturbing to me.  Unless we assume a Redmond-like position that there is one 
OS and one compiler and one software stack (based on an 80% bell curve 
argument?), different people do different things and so the definition of 
"compiler support" varies from project to project.  For example, in 
retargetable compilers (which is what I am interested in) there is more than a 
single project based on ArchC processor descriptions, and in that world, it's 
pretty much a three-ISA world of ARM, MIPS and POWER.  I certainly hope SPARC 
to be equally usable soon too, but right now it's just barely limping; Alpha, 
yes there is a one-in-a-million chance; RISC-V, that's a very sweet dream 
indeed; and x86 seems even less likely.
So yeah, three ISAs with compiler support that I could use, and like I said 
above, losing two of the three would not be much different from giving up on 
GEM5 altogether.

> We should phase out ISAS that don't support full-system unless there 
> is a clear plan to add that support.
> (The NULL ISA is an exception)
> Users expect to be able to run an OS if an ISA is supported.

From my chair it appears like this:
In another kingdom far away, there are those other people doing those other 
extremely exciting things (including FS).

For me, the catastrophic showstopper was broken remote debugging (gdb failing 
to even initiate the session) on every platform I tried, so I had to fix that.  
This was the majority of the defining discriminator between "working" and "not 
working"; FS didn't even enter into the picture.

On the other hand, I do completely agree with you about functional
verification: I need to run a tall enough software stack (such as an OS kernel) 
to believe in the simulation.  But I can have enormous stacks completely in SE. 
 E.g. Java would serve as a good illustration (not that's what we use here) of 
such a huge SW stack having no relation to FS.  I guess our situation here, is 
similar across the
board: there is Jakub's system on SPARC which is obviously tall enough but not 
quite ready yet; then there is our stack which isn't there yet; and then I 
wouldn't be surprised to learn about other people with nontrivial workloads 
which are not the FS Linux kernel.

> It reduces confusion among users. Having a handful of architectures 
> that are clearly incomplete and don't support full-system is not very 
> helpful to anyone.

Does enabling projects which result in new compilers being written and papers 
being published in journals, count as helpful?
A number of these things definitely wouldn't have happened if GEM5 lacked MIPS 
and PPC.

Boris

___
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] Memory consistency verification (and some bugs)

[Beckmann, Brad]

Hi Marco,

Thank you for initiating the discussion.  You mentioned concerns with checking 
in your patch (http://homepages.inf.ed.ac.uk/s0787712/res/mcversi_gem5.patch).  
Why do you think it needs more work?  You already have two ship its for your 
Ruby changes (review 3398).  I believe most of aspects of your larger patch 
should not be controversial.  For instance I would be disappointed if folks 
gave you a hard time for adding new pseudo instructions.  Perhaps some will 
dislike the additions to the O3 model, but personally they seem pretty minor.  
It would probably help if all your changes to the O3 code included comments on 
how they are used and why they are needed.

I would suggest posting the entire patch to reviewboard.  As I mentioned to you 
in Barcelona, eventually it would be great to add at least long regression 
tests that used it.  There is precedent to have long regression tests rely on 
code in the ext/ directory.

Thanks,

Brad


-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Andreas Hansson
Sent: Tuesday, April 12, 2016 3:08 PM
To: gem5 Developer List 
Subject: Re: [gem5-dev] Memory consistency verification (and some bugs)

Hi Marco,

This sounds good.

Regarding the external component, I certainly do not mind. I would suggest we 
prune the old and crufty McPat. That should free up some 45k LoC, and I there 
is not really any integration in place in any case.

Do you also have any updates to the MemChecker? It is currently very limited in 
that the memory usage grows very quickly. Could you perhaps shed some light on 
how this all fits together?

Thanks,

Andreas

On 12/04/2016, 22:57, "gem5-dev on behalf of Marco Elver"
 wrote:

>Hi all,
>
>I've been working on integrating McVerSi [1] (a framework for 
>simulation-based memory consistency verification) into the latest Gem5 
>version; in doing so I have also discovered new bugs (see end of email).
>
>At [1] I provide a patch and instructions on how to use McVerSi with 
>the current Gem5 version. There is a chance that (due to differing 
>checkpoints, timing, etc.) other bugs may be discovered than the 
>mentioned ones here.
>
>Ultimately, it would be good to have this in upstream, but currently 
>doesn't appear clear to me what the best approach for this is. It was 
>raised at HPCA (during discussion with Brad and David), that it might 
>be nice to have for regression testing. Comments would be appreciated.
>
>The patch at [1] needs some work to be suitable to be accepted into 
>upstream; does it still make sense to upload to RB to discuss? I am 
>also unsure if Gem5 currently provides a clean way to implement the 
>hooks required, and would rather not need to change other subsystems.
>
>(A small portion of the patch at [1] is already on the RB:
>http://reviews.gem5.org/r/3398/)
>
>Furthermore, it requires a substantial external component
>(https://github.com/melver/mc2lib) to live in ext/; should this be put 
>onto RB at the same time?
>
>Many thanks,
>
>--
>Marco Elver
>Research Associate | University of Edinburgh | ac.marcoelver.com
>
>[1] http://ac.marcoelver.com/research/mcversi
>
>
>The following are new bugs found; neither look particularly easy to fix:
>
>1. In the classic memory system, same address read->read reordering (SC 
>PER LOCATION violation) can occur with O3CPU (found while using ARM 
>ISA, but probably affects all other ISAs requiring at least same 
>address
>read->read ordering):
>
>Consider the case of a replacement (Cache::allocateBlock), which 
>chooses a block corresponding to a prior request that has already been 
>satisfied, i.e. no longer in MSHR. However, the request is still not 
>committed in the LQ on CPU side, and if we don't send an invalidation 
>to the CPU side on a replacement we may miss any potential external 
>invalidations after. This bug is found after running for about 30 min.
>
>2. In O3CPU LSQ, write->read reordering (SC PER LOCATION violation) can 
>occur in the same thread when using virtual address synonyms (found 
>with
>X86+Ruby, but will affect all other configurations that use the O3CPU):
>
>When forwarding in-flight writes from the SQ, only virtual addresses 
>are checked; if two virtual addresses map to the same physical address, 
>no forwarding takes place. I realize this might be a rare use-case for 
>the kinds of workloads being run on Gem5 right now? Found with first 
>generated test, i.e. instantly.
>
>--
>The University of Edinburgh is a charitable body, registered in 
>Scotland, with registration number SC005336.
>
>___
>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 

Re: [gem5-dev] Toward higher-fidelity Ruby memory: Using (actually) finite buffering

[Beckmann, Brad]

Thanks Joel!

This email is excellent!  I will make sure it is "required reading" by all gem5 
developers at AMD.  I have several thoughts below:

1) This is a great reminder that actions should be designed to be simple.  
Conditional checks should be handled by generating different events.  
Unfortunately we have protocols today that have pushed far too much logic 
within actions.  That leads to the conservative resource checking and very 
difficult protocols to debug.  I definitely want to take that lesson forward 
when reviewing future SLICC code.

2) You have a "ship it" from me.  Thank you for catching and fixing the bug!

3) Yes, this has been a source of confusion for a long time.  I remember 
looking at this a while back and noticing that different protocols were also 
not consistent either.  I think the solution here is not to use an integer, but 
to introduce a priority data type that is used consistently in Ruby, 
SimpleNetwork, and Garnet.

4) I personally think the solution here is to get rid of the mandatory queue.  
I do not think it models a real resource and stalling it can lead to *huge* 
performance problems.  Instead I would like to see all RubyPorts include two 
maps one for buffered, but not yet issued requests, and another for issued 
requests.

5) Have you posted a patch on this?  If it is a simple fix, then I think it 
reasonable for the SimpleNetwork.  However, we need to make sure we keep the 
SimpleNetwork simple.  This absolutely sounds like an issue that Garnet should 
handle correctly.

6 & 7) So does this cover all usage of PacketQueues in Ruby (both 
QueuedMasterPorts and QueuedSlavePorts)?  I believe all RubyPorts currently use 
the packet queues.  I would like to see them all fixed and we are willing to 
help on this.

8) I think we have a different idea of what hardware looks like.  Hardware does 
not access the cache tag and data arrays multiple times for coalesced requests. 
 There is only one access.  I believe your #9 agrees with that and somewhat 
contradicts what you are saying here.  Currently all requests sent to the 
controller requires a separate access to the tags and data as specified in the 
.sm file.  Also note that while the GPUCoalescer expects RfO protocol behavior, 
the VIPERCoalescer does not.

9) Coalescing in the caches adds a lot of unnecessary complexity to the 
protocol.  It is far easier to do that in the RubyPorts.  That is the point of 
the Sequencer and Coalescers (i.e. RubyPorts).  Do the protocol independent 
work in the RubyPorts and then only implement the necessary protocol complexity 
in the cache controllers.  I believe we all agree the RubyPorts need to be 
fixed, but I think we fix them by adding a second map for stalled, not yet 
issued requests, and removing the mandatory queue.  

10) I'm a bit confused here.  Transitions that allocate TBE entries, already 
check for TBE availability.  As long as protocols do not use z_stalls on the 
mandatory queue (BTW, we should make a goal of removing all support of 
z_stalls) independent events that do not need a TBE entry should be triggered.  
Are you seeing different behavior?  If so, what protocol?

Thanks again Joel.  This is a great reference and lists several items we should 
work on.

Brad


-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Joel Hestness
Sent: Tuesday, February 02, 2016 12:50 PM
To: gem5 Developer List
Subject: [gem5-dev] Toward higher-fidelity Ruby memory: Using (actually) finite 
buffering

Hi guys,

  I've been working on some benchmarks that place unique/new stresses on 
heterogeneous CPU-GPU memory hierarchies. In trying to tighten up the hierarchy 
performance, I've run into a number of strange cache buffering/flow control 
issues in Ruby. We've talked about fixing these things, but I've found a need 
to inventory all the places where buffering/prioritization needs work. Below is 
my list, which can hopefully serve as a starting point and offer a broader 
picture to anyone who wishes to use Ruby with more realistic memory hierarchy 
buffering. I've included my current status addressing each.

  Please let me know if you have any input or would like to help address the 
issues. Any help would be appreciated.

  Thank you!
  Joel


1) [status: not started] SLICC parses actions to accumulate the total buffer 
capacity as required by all enqueue operations within the action.
Unfortunately, the resource checking is usually overly conservative resulting 
in two problems:
   A) Many actions contain multiple code paths and not all paths get executed 
to push requests into buffers. The actual resources required are frequently 
less than SLICC's parsed value. As an example, an action with an if-else block 
containing an enqueue() on both paths will parse to require two buffers even 
though only one or the other enqueue() will be called, but not both.
   B) The resource checking can result in poorly prioritized transitions if 
they 

Re: [gem5-dev] Follow-up: Removing QueuedSlavePort from DRAMCtrl

[Beckmann, Brad]

iew Request 3116: ruby: RubyMemoryControl 
>>> delete requests
>>>
>>> Hi Andreas,
>>>
>>> Thanks for the "ship it!"
>>>
>>>
>>>> Do we really need to remove the use of QueuedSlavePort in DRAMCtrl? 
>>>> It will make the controller more complex, and I don’t want to do it 
>>>> “just in case”.
>>>>
>>>
>>> Sorry, I misread your email as offering to change the DRAMCtrl. I'm 
>>> not sure who should make that change, but I think it should get 
>>> done. The memory access response path starts at the DRAMCtrl and 
>>> ends at the RubyPort. If we add control flow to the RubyPort, 
>>> packets will probably back-up more quickly on the response path back 
>>> to where there are open buffers. I expect the DRAMCtrl QueuedPort 
>>> problem becomes more prevalent as Ruby adds flow control, unless we 
>>> add a limitation on outstanding requests to memory from directory 
>>> controllers.
>>>
>>> How does the classic memory model deal with this?
>>>
>>>   Joel
>>>
>>>
>>>
>>>> From: Joel Hestness <jthestn...@gmail.com>
>>>> Date: Tuesday, 22 September 2015 17:30
>>>> To: Andreas Hansson <andreas.hans...@arm.com>
>>>> Cc: gem5 Developer List <gem5-dev@gem5.org>
>>>>
>>>> Subject: Re: [gem5-dev] Review Request 3116: ruby: 
>>>> RubyMemoryControl delete requests
>>>>
>>>> Hi guys,
>>>>   Thanks for the discussion here. I had quickly tested other memory 
>>>> controllers, but hadn't connected the dots that this might be the 
>>>> same problem Brad/AMD are running into.
>>>>
>>>>   My preference would be that we remove the QueuedSlavePort from 
>>>> the DRAMCtrls. That would at least eliminate DRAMCtrls as a 
>>>> potential source of the QueueSlavePort packet overflows, and would 
>>>> allow us to more closely focus on the RubyPort problem when we get to it.
>>>>
>>>>   Can we reach resolution on this patch though? Are we okay with 
>>>> actually fixing the memory leak in mainline?
>>>>
>>>>   Joel
>>>>
>>>>
>>>> On Tue, Sep 22, 2015 at 11:19 AM, Andreas Hansson < 
>>>> andreas.hans...@arm.com> wrote:
>>>>
>>>>> Hi Brad,
>>>>>
>>>>> We can remove the use of QueuedSlavePort in the memory controller 
>>>>> and simply not accept requests if the response queue is full. Is 
>>>>> this needed?
>>>>> If so we’ll make sure someone gets this in place. The only reason 
>>>>> we haven’t done it is because it hasn’t been needed.
>>>>>
>>>>> The use of QueuedPorts in the Ruby adapters is a whole different 
>>>>> story. I think most of these can be removed and actually use flow 
>>>>> control. I’m happy to code it up, but there is such a flux at the 
>>>>> moment that I didn’t want to post yet another patch changing the 
>>>>> Ruby port. I really do think we should avoid having implicit 
>>>>> buffers for 1000’s of kilobytes to the largest extend possible. If 
>>>>> we really need a constructor parameter to make it “infinite” for 
>>>>> some quirky Ruby use-case, then let’s do that...
>>>>>
>>>>> Andreas
>>>>>
>>>>>
>>>>> On 22/09/2015 17:14, "gem5-dev on behalf of Beckmann, Brad"
>>>>> <gem5-dev-boun...@gem5.org on behalf of brad.beckm...@amd.com> wrote:
>>>>>
>>>>> >From AMD's perspective, we have deprecated our usage of
>>>>> RubyMemoryControl
>>>>> >and we are using the new Memory Controllers with the port interface.
>>>>> >
>>>>> >That being said, I completely agree with Joel that the packet 
>>>>> >queue finite invisible buffer limit of 100 needs to go!  As you 
>>>>> >know, we
>>>>> tried
>>>>> >very hard several months ago to essentially make this a infinite
>>>>> buffer,
>>>>> >but Andreas would not allow us to check it in.  We are going to 
>>>>> >post
>>>>> that
>>>>> >patch again in a few weeks when we post our GPU model.  Our GPU 
>>>>> >model will not work unless we increase that limit.
>>>>> &g

[gem5-dev] Help with Debugging Garnet

[Beckmann, Brad]

Hi Gem5-dev,

We have a question concerning garnet that I'm hoping someone out there can 
answer.  In particular, we are encountering a bug when trying to send ordered 
messages across garnet.  Our particular situation is the out-of-order delivery 
of two request messages being sent on the same ordered virtual network (4 
virtual channels per virtual network).  The connection is NIC->fixed 
router->NIC.  There is only one router in the connection.

The particular offending code appears in VCallocator_d::is_invc_candidate().  
The code of this function is pasted below:

 if ((m_router->get_net_ptr())->isVNetOrdered(vnet)) {
 for (int vc_offset = 0; vc_offset < m_vc_per_vnet; vc_offset++) {
int temp_vc = invc_base + vc_offset;
 if (m_input_unit[inport_iter]->need_stage(temp_vc, VC_AB_, VA_,
   
m_router->curCycle()) &&
(m_input_unit[inport_iter]->get_route(temp_vc) == outport) 
&&
(m_input_unit[inport_iter]->get_enqueue_time(temp_vc) <
 t_enqueue_time)) {

Unfortunately, like most of Garnet, there are no comments! So we are left to 
use our imagination on trying to figure out what this code is trying to do.  
The three && conditions in the if statement are particularly confusing, 
especially the "need_stage" call.  Does anyone understand what this code is 
trying to do?  It appears that it is trying to ensure that all ordered messages 
are delivered properly.  The problem is if these three are never satisified for 
all the VCs, then the function falls through and returns true.  The result is 
two messages that should be delivered in-order are enqueued on different 
virtual channels.  Thus the round-robin scheduler can easily select the second 
message first in the next stage.

Below is the detailed analysis from gdb for the 4 iterations of the loop.

We are planning to implement a fix for this, but first we need to determine 
what the code was trying to do.

Thanks,

Brad

(gdb) display m_input_unit[inport_iter]->get_enqueue_time(temp_vc)
1: m_input_unit[inport_iter]->get_enqueue_time(temp_vc) = {
  c = 1
}
(gdb) display t_enqueue_time
2: t_enqueue_time = {
  c = 38936
}
(gdb) display m_input_unit[inport_iter]->need_stage(temp_vc, VC_AB_, VA_, 
m_router->curCycle())
3: m_input_unit[inport_iter]->need_stage(temp_vc, VC_AB_, VA_, 
m_router->curCycle()) = false
(gdb) display (m_input_unit[inport_iter]->get_route(temp_vc) == outport)
4: (m_input_unit[inport_iter]->get_route(temp_vc) == outport) = true
(gdb) display m_input_unit[inport_iter]->get_route(temp_vc)
5: m_input_unit[inport_iter]->get_route(temp_vc) = 0
(gdb) p m_vc_per_vnet
$1 = 4
(gdb) c
Continuing.

Breakpoint 1, VCallocator_d::is_invc_candidate (this=0x47607e0, inport_iter=1, 
invc_iter=15)
at 
build/X86_MESI_Three_Level/mem/ruby/network/garnet/fixed-pipeline/VCallocator_d.cc:139
139 if (m_input_unit[inport_iter]->need_stage(temp_vc, VC_AB_, 
VA_,
5: m_input_unit[inport_iter]->get_route(temp_vc) = 0
4: (m_input_unit[inport_iter]->get_route(temp_vc) == outport) = true
3: m_input_unit[inport_iter]->need_stage(temp_vc, VC_AB_, VA_, 
m_router->curCycle()) = false
2: t_enqueue_time = {
  c = 38936
}
1: m_input_unit[inport_iter]->get_enqueue_time(temp_vc) = {
  c = 1
}
(gdb) c
Continuing.

Breakpoint 1, VCallocator_d::is_invc_candidate (this=0x47607e0, inport_iter=1, 
invc_iter=15)
at 
build/X86_MESI_Three_Level/mem/ruby/network/garnet/fixed-pipeline/VCallocator_d.cc:139
139 if (m_input_unit[inport_iter]->need_stage(temp_vc, VC_AB_, 
VA_,
5: m_input_unit[inport_iter]->get_route(temp_vc) = 0
4: (m_input_unit[inport_iter]->get_route(temp_vc) == outport) = true
3: m_input_unit[inport_iter]->need_stage(temp_vc, VC_AB_, VA_, 
m_router->curCycle()) = false
2: t_enqueue_time = {
  c = 38936
}
1: m_input_unit[inport_iter]->get_enqueue_time(temp_vc) = {
  c = 1
}
(gdb) c
Continuing.

Breakpoint 1, VCallocator_d::is_invc_candidate (this=0x47607e0, inport_iter=1, 
invc_iter=15)
at 
build/X86_MESI_Three_Level/mem/ruby/network/garnet/fixed-pipeline/VCallocator_d.cc:139
139 if (m_input_unit[inport_iter]->need_stage(temp_vc, VC_AB_, 
VA_,
5: m_input_unit[inport_iter]->get_route(temp_vc) = 0
4: (m_input_unit[inport_iter]->get_route(temp_vc) == outport) = true
3: m_input_unit[inport_iter]->need_stage(temp_vc, VC_AB_, VA_, 
m_router->curCycle()) = true
2: t_enqueue_time = {
  c = 38936
}
1: m_input_unit[inport_iter]->get_enqueue_time(temp_vc) = {
  c = 38936
}


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

Re: [gem5-dev] Review Request 3244: sim: Add an option to forward work items to Python

[Beckmann, Brad]

Thanks!

Brad

From: Andreas Sandberg [mailto:nore...@gem5.org] On Behalf Of Andreas Sandberg
Sent: Friday, December 18, 2015 2:10 AM
To: Default; Beckmann, Brad; Andreas Sandberg
Subject: Re: Review Request 3244: sim: Add an option to forward work items to 
Python

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



On December 17th, 2015, 5:46 p.m. GMT, Brad Beckmann wrote:
src/sim/System.py<http://reviews.gem5.org/r/3244/diff/1/?file=52126#file52126line76>
 (Diff revision 1)


def export_methods(cls, code):


76


exit_on_work_items = Param.Bool(True, "Exit from the simulation loop when "


Why make this default true?  This changes the behavior of the simulator and now 
for those apps that are annotated with work_ends, the simulation stops as soon 
as the first annotation is encountered.  Furthermore, it is not obvious that 
the simulation ends because the first annotation was encountered rather than 
the application reaches completion.



Please revert back to the old behavior.  It makes a lot more sense that by 
default, gem5 will execute the entire application and only stops prematurely if 
the user explicitly asks to exit when work items are encountered.

The intention was always to use the old behaviour by default. I'll push a fix 
shortly.


- Andreas


On December 5th, 2015, 12:29 a.m. GMT, Andreas Sandberg wrote:
Review request for Default.
By Andreas Sandberg.

Updated Dec. 5, 2015, 12:29 a.m.
Repository: gem5
Description

Changeset 11240:b7f2abdbce1a

---

sim: Add an option to forward work items to Python



There are cases where we want the Python world to handle work items

instead of the C++ world. However, that's currently not possible. This

changeset adds the forward_work_items option to the System class. Then

it is set to True, work items will generate workbegin/workend

simulation exists with the work item ID as the exit code and the old

C++ handling is completely bypassed.


Diffs

  *   src/sim/System.py (3be64e1f80ed)
  *   src/sim/pseudo_inst.cc (3be64e1f80ed)

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


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

Re: [gem5-dev] Review Request 3116: ruby: RubyMemoryControl delete requests

[Beckmann, Brad]

From AMD's perspective, we have deprecated our usage of RubyMemoryControl and 
we are using the new Memory Controllers with the port interface.

That being said, I completely agree with Joel that the packet queue finite 
invisible buffer limit of 100 needs to go!  As you know, we tried very hard 
several months ago to essentially make this a infinite buffer, but Andreas 
would not allow us to check it in.  We are going to post that patch again in a 
few weeks when we post our GPU model.  Our GPU model will not work unless we 
increase that limit.

Andreas you keep arguing that if you exceed that limit, that something is 
fundamentally broken.  Please keep in mind that there are many uses of gem5 
beyond what you use it for.  Also this is a research simulator and we should 
not restrict ourselves to what we think is practical in real hardware.  
Finally, the fact that the finite limit is invisible to the producer is just 
bad software engineering.

I beg you to please allow us to remove this finite invisible limit!

Brad



-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Andreas Hansson
Sent: Tuesday, September 22, 2015 6:35 AM
To: Andreas Hansson; Default; Joel Hestness
Subject: Re: [gem5-dev] Review Request 3116: ruby: RubyMemoryControl delete 
requests



> On Sept. 21, 2015, 8:42 a.m., Andreas Hansson wrote:
> > Can we just prune the whole RubyMemoryControl rather? Has it not been 
> > deprecated long enough?
> 
> Joel Hestness wrote:
> Unless I'm overlooking something, for Ruby users, I don't see other 
> memory controllers that are guaranteed to work. Besides RubyMemoryControl, 
> all others use a QueuedSlavePort for their input queues. Given that Ruby 
> hasn't added complete flow control, PacketQueue size restrictions can be 
> exceeded (triggering the panic). This occurs infrequently/irregularly with 
> aggressive GPUs in gem5-gpu, and appears difficult to fix in a systematic way.
> 
> Regardless of the fact we've deprecated RubyMemoryControl, this is a 
> necessary fix.

No memory controller is using QueuedSlaavePort for any _input_ queues. The 
DRAMCtrl class uses it for the response _output_ queue, that's all. If that is 
really an issue we can move away from it and enfore an upper bound on responses 
by not accepting new requests. That said, if we hit the limit I would argue 
something else is fundamentally broken in the system and should be addressed.

In any case, the discussion whether to remove RubyMemoryControl or not should 
be completely decoupled.


- Andreas


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


On Sept. 16, 2015, 6:07 p.m., Joel Hestness wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3116/
> ---
> 
> (Updated Sept. 16, 2015, 6:07 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11093:b3044de6ce9c
> ---
> ruby: RubyMemoryControl delete requests
> 
> Changes to the RubyMemoryControl removed the dequeue function, which 
> deleted MemoryNode instances. This results in leaked MemoryNode 
> instances. Correctly delete these instances.
> 
> 
> Diffs
> -
> 
>   src/mem/ruby/structures/RubyMemoryControl.cc 62e1504b9c64
> 
> Diff: http://reviews.gem5.org/r/3116/diff/
> 
> 
> Testing
> ---
> 
> Compiled gem5.debug with --without-tcmalloc. Ran large tests with Valgrind.
> 
> 
> Thanks,
> 
> Joel 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] Fix DPRINTs to reflect Address to Addr change

[Beckmann, Brad]

Hi Nilay,

Any update on this?  We need to keep consistency in the DPRINT format.  This is 
especially important for the ProtocolTrace feature.  Can you please post a fix 
to the DPRINTs?

Thanks!

Brad



-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Gutierrez, 
Anthony
Sent: Friday, September 11, 2015 4:43 PM
To: gem5 Developer List
Subject: [gem5-dev] Fix DPRINTs to reflect Address to Addr change

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
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] O3 coalescing (was Re: Review Request 2787: ruby: Fixed pipeline squashes caused by aliased requests)

[Beckmann, Brad]

Hi All,

At the bottom of Steve's message, he wrote " If pushing coalescing up into the 
LSQ doesn't let us remove it from the cache model, it doesn't seem like a big 
win to me.  I understand that it would be a win on the Ruby side, given the 
current situation there, but that raises the question in my mind of how Ruby 
deals with multiple coalescable accesses to shared downstream caches itself, 
and why can't that solution be applied to the Ruby L1 caches?"

I just want to clarify that I do not want to push the coalescing into the LSQ.  
The packets generated from the CPU have always been per-scalar-instruction, 
per-request and per-address.  I personally want to keep them this way.  The 
Ruby Sequencer contains protocol-independent logic that is part of the L1 
cache, such as coalescing from a single thread.

To answer Steve's question, Ruby allows coalescing in downstream shared caches, 
but it is protocol dependent.  The protocols can dictate what coalescing from 
multiple threads is permissible (for instance multiple writes can merge in 
weaker memory models, but not stronger ones).  Thus it is not something we can 
do in a protocol-independent fashion.

Brad


-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Steve Reinhardt
Sent: Sunday, September 13, 2015 5:51 PM
To: gem5 Developer List; Gutierrez, Anthony; Andreas Hansson; Joel Hestness
Subject: [gem5-dev] O3 coalescing (was Re: Review Request 2787: ruby: Fixed 
pipeline squashes caused by aliased requests)

On Sat, Sep 12, 2015 at 7:31 AM Andreas Hansson 
wrote:

>
>
> > On Sept. 12, 2015, 1:54 p.m., Andreas Hansson wrote:
> > > My comment seems to have gotten lost in all the different threads
> going on...bad S/N. Anyways, here it is:
> > >
> > > I am of the opinion that we should probably 1) do read/write 
> > > combining
> in the core LSQ before sending out a packet, and 2) combining of MSHR 
> targets in the L1 before propagating a miss downwards. I am not sure 
> why we would ever do it in the Sequencer. Am I missing something?
> > >
> > > This solution would also translate very well between both Ruby and 
> > > the
> classic memory system.
> >
> > Joel Hestness wrote:
> > Hi Andreas. I think we all agree with you about where coalescing
> should happen. It appears that (1) is available from particular cores (e.g.
> the O3 CPU). The problem currently is that getting (2) in Ruby would 
> require very non-trivial modification to the L1 controllers (to do
> combining) in each of the existing protocols (7 in gem5 + at least 2 
> not yet in gem5). To avoid all this protocol modification, this patch 
> is AMD's proposal to do L1 MSHR-like combining within the sequencer. 
> This proposed solution should be viewed as a stopgap on the road to 
> MSHR combining in the
> L1 controllers.
>
> I see. Thanks for the clarification.
>
> I am fairly convinced the O3 CPU is not doing any coalescing at the 
> moment. Are you sure? If not I'd say that's the place to start. 
> Coalescing in the LSQ is probably as important as coalescing of MSHR 
> targets, if not more so.
>

Forking this off into a separate thread since it's not even one of the issues 
that Joel brought up when he tried to organize things...

Andreas, can you clarify more what you mean by adding coalescing in the O3 LSQ? 
I'm not sure exactly what you mean, and I have some concerns about how that 
would work and also what it would save us.

First, are you talking about having the LSQ track memory accesses at 
cache-block granularity, and only forward a single access per cache block to 
the L1 cache?  What happens then when I have multiple read accesses to a cache 
block, but the block arrives with a pending invalidation?  In the current cache 
we would invalidate the block after completing the one outstanding access the 
L1 is aware of, which means that the subsequent accesses from the LSQ 
(forwarded after the first hit completes) would be unnecessary misses.  You 
could fix this by hanging oin to the last block in the cache even after acking 
the invalidation as long as you had additional accesses to the same block 
(actually discarding the block only on the first access to a different block), 
but that would not simplify the cache access code path :).

Second, I'm confused about how this would help, given that we need to do 
coalescing at any shared downstream (e.g., L2) cache anyway, to combine 
multiple accesses to the same block from different upstream (e.g., L1) caches.  
If pushing coalescing up into the LSQ doesn't let us remove it from the cache 
model, it doesn't seem like a big win to me.  I understand that it would be a 
win on the Ruby side, given the current situation there, but that raises the 
question in my mind of how Ruby deals with multiple coalescable accesses to 
shared downstream caches itself, and why can't that solution be applied to the 
Ruby L1 caches?

Thanks,

Steve

Re: [gem5-dev] Review Request 3043: ruby: combine RubyPort and Sequencer and rename as FirstLevelController

[Beckmann, Brad]

Hi Nilay,

Did you discard this patch?  I cannot see it on reviewboard.  I did not get a 
chance to see it, but it sounds like a substantial change.  Before you spend 
any more time on it, we should probably discuss the long-term direction here 
and make sure we are all aligned.

Thanks,

Brad


-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Nilay Vaish
Sent: Friday, August 14, 2015 8:57 PM
To: Nilay Vaish; Default
Subject: [gem5-dev] Review Request 3043: ruby: combine RubyPort and Sequencer 
and rename as FirstLevelController


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

Review request for Default.


Repository: gem5


Description
---

Changeset 11069:d41504b9
---
ruby: combine RubyPort and Sequencer and rename as FirstLevelController

This patch move the file RubyPort.* to FirstLevelController.*.  Then, it copies 
the contents of Sequencer.* to FirstLevelController.*.  Finally, it renames 
RubyPort and Sequencer to FirstLevelController and adjusts line lengths where 
ever execeeded. There are two reasons for this change:

* I find this FirstLevelController abstraction better than having separate 
RubyPort and Sequencer.  With the FirstLevelController class, we are trying to 
imply the functionality is common to all controllers that are directly attached 
to the cores.  Earlier, it appeared as if there are two components between the 
core and the actual first level controller.  Now the first level controllers in 
slicc would inherit from this new FirstLevelController class and we would 
directly connect the controller to the core, instead of going through the 
sequencer.

* The combined entity would allow us to make some changes that would ultimately 
improve ruby's performance significantly.


Now some thoughts on what lies ahead. After this patch, we would create two 
separate paths for processing of packets in the ruby memory system.  One is 
similar to the current path:  the packets would be received by the 
FirstLevelController, which would carry out the same functionality that 
RubyPort and Sequencer used to carry out earlier.  We would convert packet to 
RubyRequest and store the packet in the FirstLevelController, encapsulated in a 
SequencerRequest which is kept in a hash map.  When the request gets 
fullfilled, the reply would be processed as before.

The second path would process the packet as the erstwhile RubyPort used to do 
and hand it to the controller defined in SLICC.  The controller would directly 
work with the packet, so no RubyRequest or SequencerRequest would be created 
and no hash map insertion/lookups/deletions would happen.  In the common case 
of hits, the packet would be returned immediately.  On a miss the TBE would 
hold the packet till the request gets fullfilled.  Actually, the TBEs would now 
have a vectorPacket * so that they can coalesce multiple requests for the 
same block.

I would make the protocol changes only to MESI Two Level and Three Level 
protocols.  For the rest we would continue using the original path.  The 
changes to protocols using the original path would kept as low as possible, 
with the intention being absolutely no changes.  It is expected that we would 
see considerable performance improvement for protocols using the new path.  It 
is already known that we would see about 6% performance improvement by dropping 
RubyRequest and SequencerRequest.  Avoiding hashmap would provide us further 
improvements.

While I have not given this much thought, but we might ultimately be able to 
work with ports in controllers written in SLICC.  Doing so would avoid the 
extra queueing cost that we currently pay when we pick packets from ports and 
queue them in the first level controller's mandatory queue.


Diffs
-

  configs/example/fs.py 110cce93d398
  configs/ruby/MESI_Two_Level.py 110cce93d398
  src/mem/ruby/system/System.cc 110cce93d398
  src/mem/slicc/symbols/StateMachine.py 110cce93d398
  tests/configs/pc-simple-timing-ruby.py 110cce93d398
  src/mem/ruby/profiler/Profiler.cc 110cce93d398
  src/mem/ruby/slicc_interface/AbstractController.hh 110cce93d398
  src/mem/ruby/slicc_interface/AbstractController.cc 110cce93d398
  src/mem/ruby/slicc_interface/AbstractDMAController.hh PRE-CREATION
  src/mem/ruby/slicc_interface/AbstractDMAController.cc PRE-CREATION
  src/mem/ruby/slicc_interface/Controller.py 110cce93d398
  src/mem/ruby/slicc_interface/FirstLevelController.hh PRE-CREATION
  src/mem/ruby/slicc_interface/FirstLevelController.cc PRE-CREATION
  src/mem/ruby/slicc_interface/SConscript 110cce93d398
  src/mem/ruby/system/CacheRecorder.hh 110cce93d398
  src/mem/ruby/system/CacheRecorder.cc 110cce93d398
  src/mem/ruby/system/DMASequencer.hh 110cce93d398
  src/mem/ruby/system/DMASequencer.cc 110cce93d398
  

Re: [gem5-dev] changeset in gem5: ruby: remove message buffer node

[Beckmann, Brad]

In fact stl does use the comparison.  That is how I ran into the bug.

#0  0x003877630265 in raise () from /lib64/libc.so.6
#1  0x003877631d10 in abort () from /lib64/libc.so.6
#2  0x0038776296e6 in __assert_fail () from /lib64/libc.so.6
#3  0x012a710f in operator (lhs=..., rhs=...)
at build/gpu_RfO/mem/ruby/slicc_interface/Message.hh:124
#4  0x012a88eb in std::greaterstd::shared_ptrMessage ::operator() (
this=0x7fffb9e0, __x=..., __y=...)
at 
/tool/pandora64/.package/gcc-4.8.0/include/c++/4.8.0/bits/stl_function.h:226
#5  0x012a7e08 in 
std::__adjust_heap__gnu_cxx::__normal_iteratorstd::shared_ptrMessage*, 
std::vectorstd::shared_ptrMessage, std::allocatorstd::shared_ptrMessage  
 , long, std::shared_ptrMessage, std::greaterstd::shared_ptrMessage   
(__first=..., __holeIndex=0, __len=3, __value=..., 
__comp=...)
at /tool/pandora64/.package/gcc-4.8.0/include/c++/4.8.0/bits/stl_heap.h:309
#6  0x012a7808 in 
std::__pop_heap__gnu_cxx::__normal_iteratorstd::shared_ptrMessage*, 
std::vectorstd::shared_ptrMessage, std::allocatorstd::shared_ptrMessage  
 , std::greaterstd::shared_ptrMessage   (__first=..., 
__last=..., __result=..., __comp=...)
at /tool/pandora64/.package/gcc-4.8.0/include/c++/4.8.0/bits/stl_heap.h:338
#7  0x012a73ba in 
std::pop_heap__gnu_cxx::__normal_iteratorstd::shared_ptrMessage*, 
std::vectorstd::shared_ptrMessage, std::allocatorstd::shared_ptrMessage  
 , std::greaterstd::shared_ptrMessage   (__first=..., 
__last=..., __comp=...)
at /tool/pandora64/.package/gcc-4.8.0/include/c++/4.8.0/bits/stl_heap.h:367
#8  0x013d6182 in WireBuffer::dequeue (this=0x629fda0)
at build/.../mem/ruby/structures/WireBuffer.cc:97

Brad



-Original Message-
From: Nilay Vaish [mailto:ni...@cs.wisc.edu] 
Sent: Thursday, July 30, 2015 10:03 AM
To: Beckmann, Brad
Cc: gem5 Developer List
Subject: RE: [gem5-dev] changeset in gem5: ruby: remove message buffer node

On Thu, 30 Jul 2015, Beckmann, Brad wrote:

 Hi Nilay,

 As part of our check-ins tomorrow, I would like to check in a single 
 line bug fix to this patch.  Specifically we plant to remove the 
 assert in the overload function of the MsgPtr operator.  It is 
 perfectly valid to compare the same MsgPtr to itself.  Currently the 
 assert prevents such a comparison.

 I don't expect this to be much of an issue, but I wanted you to be aware.

 Thanks,

 Brad


 Specific patch:


 diff --git a/src/mem/ruby/slicc_interface/Message.hh 
 b/src/mem/ruby/slicc_interface/Message.hh
 --- a/src/mem/ruby/slicc_interface/Message.hh
 +++ b/src/mem/ruby/slicc_interface/Message.hh
 @@ -121,7 +121,6 @@
 const Message *r = rhs.get();

 if (l-getLastEnqueueTime() == r-getLastEnqueueTime()) {
 -assert(l-getMsgCounter() != r-getMsgCounter());
 return l-getMsgCounter()  r-getMsgCounter();
 }
 return l-getLastEnqueueTime()  r-getLastEnqueueTime();


I am ok with the change.  But I am surprised you end up comparing a message to 
itself.  As I understand, this operator is only used for pushing to and popping 
from message buffers.  And I would be surprised if stl compares an object to 
itself for heap/priority queue operations.

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

Re: [gem5-dev] Problem Loading SimpleNetwork from INI Config File

[Beckmann, Brad]

Nilay,

Please be more professional when responding to questions.  If you have a 
particular idea on how to fix the problem, we would appreciate if you described 
it rather than leaving us a trail of breadcrumbs.

Please note that your patch, 10311, is the one that breaks the tenet that 
ClockedObjects, which include ports, are MemObjects.  It is unfortunate that 
our regression tester does not test config.ini loading with ruby and did not 
realize that the SimpleNetwork is different than all other ClockedObjects.  
However, I do not believe revision 10458 is at fault here.  Rather it is 
SimpleNetwork's unconventional use of ports.

We appreciate your help on this matter.  Important work is currently blocked on 
this bug.

Thank you,

Brad




-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Nilay Vaish
Sent: Tuesday, June 23, 2015 3:10 PM
To: gem5 Developer List
Subject: Re: [gem5-dev] Problem Loading SimpleNetwork from INI Config File

On Tue, 23 Jun 2015, Gross, Joe wrote:

 Hi Nilay,

 I've looked through these but don't see any obvious special behaviors 
 that would apply to the SimpleNetwork deserialization. However, 
 neither of these have changed significantly in quite a while, so I 
 think whatever broke was in Network or SimpleNetwork.


Joe, src/sim/cxx_manager.cc did not used to exist until revision 10458. 
So, you are completely incorrect on whatever you think is broken.  Compare the 
functions src/python/swig/pyobject.cc:connectPorts() and 
CxxConfigManager::bindPort().


 Since you're the author of a variety of changes to Network and 
 SimpleNetwork between when this was working and now, I thought you would 
 know fairly quickly what changed and why SimpleNetwork no longer works 
 in this framework. If you can offer something specific (or better yet, a 
 patch), that would help resolve this bug. Thanks!


I would really prefer that you learn how to figure out what a particular 
piece of code might be doing.  Earlier I told you what files to compare. 
I have now told you what functions to compare.  If you are still not able 
to figure out, I'll suggest another step towards the solution that I have 
in mind.


--
Nilay
___
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] Ruby serialize removing event queue head

[Beckmann, Brad]

You could certainly do that.  You are absolutely correct that a Ruby simulation 
does not need a trace to run from a checkpoint.

Brad



-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Timothy M Jones
Sent: Thursday, June 18, 2015 12:32 AM
To: gem5-dev@gem5.org
Subject: Re: [gem5-dev] Ruby serialize removing event queue head

Hi Brad,

On 17/06/2015 21:38, Beckmann, Brad wrote:
 The benefit for creating at trace, rather than just inserting data into the 
 cache, is two-fold.  First, by creating a trace from a very large cache 
 system, one can warmup caches of different sizes, associativities and even 
 completely different cache hierarchies/configurations from a single trace.  
 Second, and probably more important, Ruby protocols rely on timing requests 
 to set cache block state to the unique states used by a particular protocol.  
 Often Ruby is used to compare different protocols and this process allows us 
 to compare protocols using the exact same checkpoint.

Thanks for the explanation.  OK, so I understand why you want to have a trace, 
but is there any need for it, or could you just start at a checkpoint with a 
totally empty cache (as in the classic model)? 
Basically, is this trace simply a way to avoid the need to warm up the caches 
after a checkpoint?

At the moment I can create the trace at a checkpoint, which is progress, but I 
get problems both in the simulator and simulated system when restoring from the 
checkpoint.  I'd like to know whether to invest the time in getting this to 
work, or whether I should simply implement
memWriteback() for ruby to flush dirty data before a checkpoint, then do away 
with the trace altogether.

Cheers
Tim

--
Timothy M. Jones
http://www.cl.cam.ac.uk/~tmj32/
___
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] Ruby serialize removing event queue head

[Beckmann, Brad]

Hi Tim,

I have not been completely following this thread, but I can answer your 
question about unserializing cache contents.

The benefit for creating at trace, rather than just inserting data into the 
cache, is two-fold.  First, by creating a trace from a very large cache system, 
one can warmup caches of different sizes, associativities and even completely 
different cache hierarchies/configurations from a single trace.  Second, and 
probably more important, Ruby protocols rely on timing requests to set cache 
block state to the unique states used by a particular protocol.  Often Ruby is 
used to compare different protocols and this process allows us to compare 
protocols using the exact same checkpoint.

I hope that helps,

Brad




-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Timothy M Jones
Sent: Wednesday, June 17, 2015 3:16 AM
To: gem5 Developer List
Subject: Re: [gem5-dev] Ruby serialize removing event queue head

Thanks Nilay and Joel for the information.

I've been playing around with this over the past few days and I can't work out 
what the point of the flush is.  The CacheRecorder already has a copy of all 
the data blocks in the trace before the flush starts. 
Removing the flush event and subsequent simulation produces exactly the same 
system.ruby.cache.gz file as with it in, so I guess it's safe to remove them

So, with that out of the way, I can create checkpoints and exit the simulator 
correctly.  I'm not 100% sure about restoring the checkpoint though, and it 
seems a little hacky.  Is there a reason it has to unserialise by inserting 
memory requests into the event queue - couldn't it just write the data into the 
correct locations in the caches?

There's also a question about whether ruby should be recording its state 
anyway.  Shouldn't it be doing the same as the classic memory system caches and 
implementing memWriteback() to flush all dirty data out before checkpointing 
happens, then it doesn't need to trace anything? 
(Maybe I'm opening a can of worms, but I thought I'd just ask!)

Cheers
Tim


On 13/06/2015 18:03, Joel Hestness wrote:
 Hey guys,
I'm pretty sure Tim is correct that the checkpointing bugs were 
 introduced earlier than the changeset Nilay points to; gem5-gpu is 
 currently using gem5 rev 10645 
 http://repo.gem5.org/gem5/rev/cd95d4d51659, and we cannot get 
 reliable checkpoint and restore with it. Note that Tim's bug may not 
 be the only checkpointing bug that exists right now.

To answer Tim's question: While taking a checkpoint, Ruby 
 commandeers the event queue to inject flushing memory accesses into 
 the caches. This is used to generate a trace of cache contents, which 
 can be used to warm up the caches on checkpoint restore. To take over 
 control of the event queue, Ruby clears the event at the queue head (I 
 think this assumes there is only 1 event in the queue? This should 
 probably be checked), and then adds it's own event for the cache 
 flushing operation. After the caches have been flushed (simulate() 
 call in RubySystem::serialize()), Ruby restores the head event that 
 was in the queue and rolls back the current tick.

One way to check if this cooldown operation is at fault for 
 unreliable checkpointing is to simply comment out the event queue 
 commandeering, and try to take a checkpoint. You may also be able to 
 test checkpoint restore by commenting the cache warm-up code in 
 RubySystem::unserialize(). If checkpoint and restore work without the 
 event queue commandeering, it is likely that the event queue 
 manipulation is problematic.

I'd also recommend trying to take a checkpoint and restore with 
 simulation specifying the gem5 flag --debug-flag=RubyCacheTrace, which 
 will show what the cache flushing and warm-up are doing, respectively.

Joel



 On Sat, Jun 13, 2015 at 9:48 AM, Nilay Vaish ni...@cs.wisc.edu 
 mailto:ni...@cs.wisc.edu wrote:

 Your bisection is not right.  You might want to take a look at the
 following changeset:


 changeset:   10756:f9c0692f73ec
 user:Curtis Dunham curtis.dun...@arm.com
 mailto:curtis.dun...@arm.com
 date:Mon Mar 23 06:57:36 2015 -0400
 summary: sim: Reuse the same limit_event in simulate()


 I suggest that you revert this changeset in your repo while I think
 about what needs to be done.

 --
 Nilay



 On Sat, 13 Jun 2015, Timothy M Jones wrote:

 Hi again,

 Further to this message, I've used hg bisect to find the
 revision that breaks checkpointing with ruby.  It's revision
 10524 that Nilay committed in November that's the first bad
 changeset.  It fails with the panic() on the missing event that
 I wrote about previously.

 I've scanned through the diff and can't immediately see any
 reason why this would break serialisation, although it does
 remove some of the code to 

Re: [gem5-dev] Review Request 2551: ruby: slicc: have a static MachineType

[Beckmann, Brad]

Hi Joel,

The patch adds convenience as you point out.  Please let us add it.

The patch that removed the GenericMachineType was checked in without discussion 
or receiving any ship its (see: http://reviews.gem5.org/r/1899/).  That is not 
the community setting a precedent.  Sure we all should have done better staying 
on top of those reviews back in 2013.  However, that doesn't mean we should 
move forward with restricting developers on what information can be passed 
between ruby and the .sm files.  This is simulator.  Let's make it as easy to 
use as possible.
 
More recently, there was an exchange of emails between various gem5 developers 
prior to this patch (see attachment).  There was some consensus that led to 
this patch, however I realize that you did not participate in that conversation.

Thanks,

Brad


-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Joel Hestness
Sent: Friday, May 29, 2015 9:08 AM
To: gem5 Developer List
Subject: Re: [gem5-dev] Review Request 2551: ruby: slicc: have a static 
MachineType

Hey Brad,

The definition of MachineType is not only needed for protocol specific
 analysis within Ruby, but it needed for protocol specific mapping functions.

 I would like to point out that today, the function 
 map_Address_to_Directory in RubySlicc_ComponentMapping.hh requires 
 that all protocols define a Directory machine.  By adding this patch, 
 that requirement will no longer be necessary.  It will also allow 
 folks to add different protocol specific mapping functions without 
 breaking all other protocols.


You are suggesting that one instance of this should merit changing the whole 
codebase - I disagree. You should note that the map_Address_to_Directory 
function is a convenience so that .sm files need not create the MachineID to 
send to a directory. It would be very straightforward to remove the reference 
to MachineType_Directory in RubySlicc_ComponentMapping.hh and make .sm files 
generate the MachineID; map_Address_to_Directory would just return the node ID. 
If someone wanted to create a snooping Ruby protocol, this would be a good 
first step.

Further, there is significant precedent that gem5 has been moving toward 
MachineType independence in protocol-independent code. We removed the 
GenericMachineType, dynamically generate the MachineTypes enum, and removed 
references to protocol-specific MachineTypes in the sequencer. Let's be 
forward-thinking about the codebase rather than revisionist.


Let's not insist that every feature added to Ruby must have a mainline
 use.  The public tree should prioritize being a useful baseline that 
 others can build on top of rather than trying to achieve perfection.


I agree with you that the public tree should be easily extensible, but it 
should also prioritize guiding users toward appropriate use of the existing 
infrastructure. In this case, there are no necessary mainline uses and poorly 
understood non-mainline uses for protocol-specific MachineType handling in 
protocol-independent code. We have also discussed that protocol-specific 
profiling can be supported by adding stats in SLICC.
Stats would be a far more extensible solution than allowing protocol-specific 
MachineTypes to permeate the codebase.

It is in the community's interest to add stats to SLICC. There needs to be 
forcing functions to make these things happen somewhere.

  Joel



-Original Message-
 From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Joel 
 Hestness
 Sent: Monday, May 11, 2015 11:15 AM
 To: gem5 Developer List
 Subject: Re: [gem5-dev] Review Request 2551: ruby: slicc: have a 
 static MachineType

 Hi guys,
   More thoughts are inlined below:


  Hi guys,
 
  @Nilay: Thanks for clarifying the desired MachineType usage.
 
  I understand the aims now, and I still disagree with statically 
  defined MachineTypes. SLICC is already very powerful, and it only 
  makes sense to add features, not contract them. In this case, scons 
  and SLICC already do the following for us: (1) they allow 
  dynamically extending the list of protocols in any SConscript 
  ('all_protocols'
  variable), (2) they traverse all directories to find all 
  protocol-related files, and (3) they generate all the MachineType code.
 This is nearly everything we need!
 
  So, it seems that we're divided on whether we should just make 
  MachineTypes work or do this the right way. I spent a little 
  time today to assemble a patch that dynamically generates the 
  MachineType enum from the superset of all protocol controller 
  definitions. Here it
 is:
  http://reviews.gem5.org/r/2773/
 
  Overall, I feel that the vision should be that SLICC be able to 
  generate and build any/all protocols in a single build operation 
  (like gem5's SE+FS mode merge). I suspect that direction will 
  involve eliminating statically defined types, since they often need 
  to be updated per-protocol, which tends to cause merge headaches.
 

Re: [gem5-dev] Review Request 2551: ruby: slicc: have a static MachineType

[Beckmann, Brad]

It has been a couple weeks since we discussed this patch.  I hope that folks 
can see this patch in a different light.

The definition of MachineType is not only needed for protocol specific analysis 
within Ruby, but it needed for protocol specific mapping functions.

I would like to point out that today, the function map_Address_to_Directory in 
RubySlicc_ComponentMapping.hh requires that all protocols define a Directory 
machine.  By adding this patch, that requirement will no longer be necessary.  
It will also allow folks to add different protocol specific mapping functions 
without breaking all other protocols.

Let's not insist that every feature added to Ruby must have a mainline use.  
The public tree should prioritize being a useful baseline that others can build 
on top of rather than trying to achieve perfection.

Thanks,

Brad



-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Joel Hestness
Sent: Monday, May 11, 2015 11:15 AM
To: gem5 Developer List
Subject: Re: [gem5-dev] Review Request 2551: ruby: slicc: have a static 
MachineType

Hi guys,
  More thoughts are inlined below:


 Hi guys,

 @Nilay: Thanks for clarifying the desired MachineType usage.

 I understand the aims now, and I still disagree with statically 
 defined MachineTypes. SLICC is already very powerful, and it only 
 makes sense to add features, not contract them. In this case, scons 
 and SLICC already do the following for us: (1) they allow dynamically 
 extending the list of protocols in any SConscript ('all_protocols' 
 variable), (2) they traverse all directories to find all 
 protocol-related files, and (3) they generate all the MachineType code. This 
 is nearly everything we need!

 So, it seems that we're divided on whether we should just make 
 MachineTypes work or do this the right way. I spent a little time 
 today to assemble a patch that dynamically generates the MachineType 
 enum from the superset of all protocol controller definitions. Here it is:
 http://reviews.gem5.org/r/2773/

 Overall, I feel that the vision should be that SLICC be able to 
 generate and build any/all protocols in a single build operation 
 (like gem5's SE+FS mode merge). I suspect that direction will involve 
 eliminating statically defined types, since they often need to be 
 updated per-protocol, which tends to cause merge headaches.

  Joel




 Joel, AMD might have used machine types for which no definition exists 
 in any of the protocols.  This used to happen in erstwhile GenericMachineType.


I'm not necessarily advocating for my patch, but we shouldn't allow code that 
functions on non-existent types. Such would be dead code and doesn't have a 
place in the mainline repo. Some GenericMachineTypes may have gone unused, but 
only because they were statically defined. Dynamically defined types would 
eliminate the existence of dead types.


I am not in favor of committing Joel's patch or the one I wrote (which is
 why I had taken it off the reviewboard).  We should not add protocol 
 specific code to files that are not protocol-specific.  Such code 
 should reside in protocol specific .sm files.  If required, SLICC 
 should be modified.  I am unable to think of any technical difficulty 
 that prevents us from adding statistical variables to .sm files.  We 
 already have cache hits and misses being collected in .sm files.

 I am not in favor of the argument that we should stick to same way as 
 things were done in past.  If in past something was done incorrectly / 
 inefficiently / not-correct-completely, we should be willing to change it.
 In the current context, protocol-specific code in protocol-independent 
 files was not the right thing to do.  Therefore, we should be 
 unwilling to allow such code.


After reviewing this thread and the prior thread on protocol-specific profiling 
(https://www.mail-archive.com/gem5-dev@gem5.org/msg13084.html), I agree with 
Nilay that we should disallow protocol-specific activity in 
protocol-independent code. Currently we don't have any such activity in 
mainline gem5, and we don't have a well-defined use case for it that we can 
review. If we think there is a real need for it, I'd request that the code be 
posted for us to review. Having specific use cases would be helpful in deciding 
whether/how to manage it.

To riff on Nilay's suggestions for modifying SLICC: It appears it would be 
straightforward to add protocol-specific profiling within protocol files by 
extending SLICC to add gem5 stats. While it would be more complex, it even 
looks feasible to add enough machine inheritance that different protocols could 
share common profiling functionality (we could also share other things if we 
were so inclined).

  Joel


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

Re: [gem5-dev] Review Request 2808: slicc: improved stalling support in protocols

[Beckmann, Brad]

Reponses below marked with [BB]:

-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Nilay Vaish
Sent: Tuesday, May 19, 2015 3:41 PM
To: Default
Subject: Re: [gem5-dev] Review Request 2808: slicc: improved stalling support 
in protocols

On Tue, 19 May 2015, Brad Beckmann wrote:



 On May 14, 2015, 2:53 p.m., Nilay Vaish wrote:
 First, why do you need both stallPort() and check_next_cycle()?  Both are 
 going to call scheduleEvent(Cycles(1)).

 Second, why not just expose scheduleEvent() function and let the protocol 
 author use it in whatever way they like.
 Why add a new keyword for calling a function that simply calls another 
 function?

 Brad Beckmann wrote:
 stallPort() is only meant to be used within an in_port, while 
 check_next_cycle() is a pre-defined function that can be called within an 
 action.  You are correct that this patch could just use check_next_cycle() 
 and avoid introducing stallPort().  I preferred the stallPort() call within 
 the in_port just to make it clear that the entire port is being stalled when 
 stallPort() is called rather than triggering an event.

 Nilay Vaish wrote:
 stallPort() not actually stalling the port.  It is just calling 
 scheduleEvent().
 Is this not misleading?  Stalling should mean nothing would get processed
 after the call to stallPort().

 Secondly, why do we want to add these special cases?  Let's just expose 
 scheduleEvent()
 function through some .sm file and the protocol author can directly use 
 it for whatever
 purpose they want to.  Or else, you can add stallPort() and 
 check_next_cycle() as functions in some .sm
 file and use them in your protocols.  I think we are unnecessarily 
 adding special
 cases to the SLICC compiler.

 StallPort is in fact stalling the port by not dequeuing the message 
 from the message buffer.  Nothing eles on that port will be processed 
 if one does dequeue the head pointer.

stallPort() gets converted to scheduleEvent(Cycles(1));  How is this stalling 
the port?  What ever statement follows stallPort() would still be executed.  
Please provide some code snippet so that I can understand how a port will get 
stalled.

[BB] Sure, if someone were to insert code after the call to stallPort(), then 
that would be executed, but the port is still stalled on the current message.  
We use this message so that our in_port logic is easier to read and doesn't 
lead to deadlock.

In_port(...) {
  if (buffer.isRead()) {
peek (...) {
If (conditions exist to process the next message) {
  ...
} else {
  stallPort();
}
 }
   }
 }



 SLICC has not supported direct event queue manipulation.  These APIs 
 allow the experience SLICC programmer to manage message processing 
 without calling the event queue APIs.  You are absolutely right that 
 these two functions generate the same code and could be replaced by 
 adding the event queue APIs to the RubySlicc*.sm files.

Note that SLICC is a language.  SLICC supports functions and we can define a 
function check_next_cycle() that calls scheduleEvent(Cycles(1)), say in 
RubySlicc_utils.sm.  We would need to provide a prototype for
scheduledEvent() function which is fine with me.  Similarly you can define 
another function stallPort() which also does the same thing.  I am not in favor 
of changing the language just for these two functions.  The readability of code 
in *.sm files would not change at all.

[BB]  Just because you don't believe this improves readability, doesn't make 
that true for others.  You are welcome to post the patch you are proposing and 
I will give it a ship it.  I prefer to do it in a different way because I think 
it improves readability.

--
Nilay
___
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 2776: ruby: cleaner ruby tester support

[Beckmann, Brad]

The reason why the requests cannot be processed is not a resource issue.  It is 
usually an address contention issue.  When the address contention issue is 
resolved, a large racey burst of requests is issued at once.  That is exactly 
the type of scenario that finds protocol bugs.  The request buffering you are 
referring to is not in the queued port, rather the buffering occurs in the 
Sequencer (or other similar objects).  The queued port buffering happens on the 
response path back to the RubyTester.  The RubyTester itself can deal with a 
very large amount of responses at once.  The queued port limit is reached 
simply because a large number of responses come back at once.

Brad


-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Nilay Vaish
Sent: Wednesday, May 13, 2015 9:47 AM
To: gem5 Developer List
Subject: Re: [gem5-dev] Review Request 2776: ruby: cleaner ruby tester support

On Wed, 13 May 2015, Brad Beckmann wrote:



 On May 12, 2015, 5:45 a.m., Andreas Hansson wrote:
 src/mem/packet_queue.cc, line 117
 http://reviews.gem5.org/r/2776/diff/1/?file=45138#file45138line117

 I strongly disagree with this change. This buffer should not 
 exist, and even 100 packets is a stretch. Any module hitting this 
 needs to recondiser how it deals with flow control

 Brad Beckmann wrote:
 I would agree with you that the buffer should not exist, but removing 
 the buffer goes well beyond this patch.  The worst part about the buffer is 
 the size is not visible to the sender.  It is a really bad design, but for 
 now we need to get around the immediate problem.  Later we can discuss how 
 and who will fix this right.

 We've discussed the proposal in the past to increase the size, but 
 unfortunately we have not came to a resolution.  We absolutely need to 
 resolve this now.  We cannot use the ruby tester with our upcoming GPU model 
 without this change.

 The important thing to keep in mind is that the RubyTester is designed 
 to stress the protocol logic and it creates contention scenarios that would 
 not exist in a real system.  The RubyTester finds bugs in the matter of 
 seconds that may not be encountered in hours of real workload simulation.  
 It does this by sending large bursts of racey requests.  Bottomline: the 
 RubyTester needs this large value.

 Andreas Hansson wrote:
 I would argue that if you need flow control, you should not use the 
 QueuedPorts, and rather use a bare-metal MasterPort, and deal with the 
 flow control. There is no point in adding flow control (or buffer 
 visibility) to the QueuePort in my opinion.

 I'd suggest to switch to a MasterPort either as part of this patch, or a 
 patch before it. That way you have no implicit buffer, and no need to create 
 kilobytes of invisible buffering in the system.

 The RubyPort and the Ruby Tester predate MasterPorts and QueuedPorts. 
 Your suggestion goes far beyond this patch.  Reimplementing RubyPort's
 m5 ports to inherit from a different base port is a very signficant 
 change with many, many implications beyond the Ruby Tester.  That is a 
 pretty unreasonable request.

 Please keep in mind that I was not the one who decided RubyPort to use 
 QueuedPorts. That decision was made back in 2012 with patches from 
 your group 8914:8c3bd7bea667, and 8922:17f037ad8918.




Brad, I think you are forgetting one thing here.  If the packets / memory 
requests are in a packet queue of the queuedport, then they have not been seen 
by the ruby memory system.  So, if your memory system cannot process requests 
at the rate at which the tester is issuing them, you are any way not going to 
see the desired behavior.  In which case buffering them in the tester should 
also be OK.

--
Nilay
___
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 2551: ruby: slicc: have a static MachineType

[Beckmann, Brad]

First off, I was also seeing the private patch error.  I think Nilay changed 
the access permissions on that particular patch for a moment.  It should now be 
accessible again.

Let’s be clear, the MachineType object and its associated functions were static 
before this change.  That is a big problem that we will need to fix soon.  
You’ll see more from Brandon Potter on this soon.

I believe this patch actually is a step in the right direction as far as 
removing the static dependencies on MachineType.  Before this patch, the 
MachineType enum needed to be inclusive of all possible machine types created 
by the protocols.  Thus the RubySlicc_Export.sm file was a global file that 
needed to be modified by every protocol that introduced a new machine name.  
That dependency goes away with this change.

Yes, we do have patches in the pipeline that implement non-CPU cache 
controllers.  They depend on this patch being checked in.

Brad




From: Jason Power [mailto:power...@gmail.com]
Sent: Friday, May 08, 2015 11:57 AM
To: gem5 Developer List; Beckmann, Brad; Nilay Vaish
Subject: Re: [gem5-dev] Review Request 2551: ruby: slicc: have a static 
MachineType

Hi Brad,
I personally would not like to see this patch pushed as it is. It breaks our 
workflow for gem5-gpu. Also, it seems to me that making the MachineTypes static 
is a step backwards. It's already hard with Ruby to create a protocol that 
isn't a traditional CPU-oriented protocol, and by not allowing new machine 
types (easily) it makes it that much harder.

I have to admit it's been a long time since I looked at this patch, and 
unfortunately I can't right now because I'm getting an error with reviewboard 
This review request is private. You must be a requested reviewer, either 
directly or on a requested group, and have permission to access the repository 
in order to view this review request. Strange.

Brad, do you have any patches in the (very near) pipeline that will allow for 
more MachineTypes than just the basic CPU-oriented caches? I suppose I could be 
convinced to modify our protocols once, but I really don't want to have to 
change them with every gem5 update more than we already do.

Overall, I can't remember what problem this patch originally solves. Was the 
problem that the Ruby stats depended on a static number of 
(Generic)MachineTypes? If this is the problem this patch solves, wouldn't it be 
better to instead make the stats accept dynamic MachineTypes?

If the rest of the community disagrees with me and wants this patch as is, we 
can deal here at gem5-gpu. I would just much rather keep the changes we have to 
the mainline gem5 minimal as merges are already pretty hellish as it is.

Thanks,
Jason

On Fri, May 8, 2015 at 12:07 PM Beckmann, Brad 
brad.beckm...@amd.commailto:brad.beckm...@amd.com wrote:
Hi Nilay,

Can you check this patch and the previous patch (review 2550) in the repo?  We 
will be posting a series of patches next week and they depend on these two 
patches.

Thanks,

Brad



From: Brad Beckmann 
[mailto:nore...@reviews.gem5.orgmailto:nore...@reviews.gem5.org] On Behalf Of 
Beckmann, Brad
Sent: Monday, April 27, 2015 3:30 PM
To: Nilay Vaish; Beckmann, Brad; Default
Subject: Re: Review Request 2551: ruby: slicc: have a static MachineType

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



Ship it!

Ship It!


- Brad Beckmann


On December 4th, 2014, 6:08 p.m. UTC, Nilay Vaish wrote:
Review request for Default.
By Nilay Vaish.

Updated Dec. 4, 2014, 6:08 p.m.
Repository: gem5
Description

Changeset 10594:b25131489b95

---

ruby: slicc: have a static MachineType

This patch moves from a dynamically defined MachineType to a statically

defined one.  The need for this patch was felt since a dynamically defined

type prevents us from having types for which no machine definition may

exist.



The following changes have been made:

i. each machine definition now uses a type from the MachineType enumeration

instead of any random identifier.  This required changing the grammar and the

*.sm files.



ii. MachineType enumeration defined statically in RubySlicc_Exports.sm.


Diffs

  *   src/mem/protocol/MESI_Two_Level-L1cache.sm (fea29fc045ee)
  *   src/mem/protocol/MESI_Two_Level-L2cache.sm (fea29fc045ee)
  *   src/mem/protocol/MESI_Two_Level-dir.sm (fea29fc045ee)
  *   src/mem/protocol/MESI_Two_Level-dma.sm (fea29fc045ee)
  *   src/mem/protocol/RubySlicc_Exports.sm (fea29fc045ee)
  *   src/mem/slicc/ast/DeclListAST.py (fea29fc045ee)
  *   src/mem/slicc/ast/MachineAST.py (fea29fc045ee)
  *   src/mem/slicc/parser.py (fea29fc045ee)
  *   src/mem/slicc/symbols/SymbolTable.py (fea29fc045ee)
  *   src/mem/slicc/symbols/Type.py (fea29fc045ee)

View Diffhttp://reviews.gem5.org/r/2551/diff/


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

Re: [gem5-dev] Review Request 2551: ruby: slicc: have a static MachineType

[Beckmann, Brad]

Hi Nilay,

Can you check this patch and the previous patch (review 2550) in the repo?  We 
will be posting a series of patches next week and they depend on these two 
patches.

Thanks,

Brad



From: Brad Beckmann [mailto:nore...@reviews.gem5.org] On Behalf Of Beckmann, 
Brad
Sent: Monday, April 27, 2015 3:30 PM
To: Nilay Vaish; Beckmann, Brad; Default
Subject: Re: Review Request 2551: ruby: slicc: have a static MachineType

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



Ship it!

Ship It!


- Brad Beckmann


On December 4th, 2014, 6:08 p.m. UTC, Nilay Vaish wrote:
Review request for Default.
By Nilay Vaish.

Updated Dec. 4, 2014, 6:08 p.m.
Repository: gem5
Description

Changeset 10594:b25131489b95

---

ruby: slicc: have a static MachineType

This patch moves from a dynamically defined MachineType to a statically

defined one.  The need for this patch was felt since a dynamically defined

type prevents us from having types for which no machine definition may

exist.



The following changes have been made:

i. each machine definition now uses a type from the MachineType enumeration

instead of any random identifier.  This required changing the grammar and the

*.sm files.



ii. MachineType enumeration defined statically in RubySlicc_Exports.sm.


Diffs

  *   src/mem/protocol/MESI_Two_Level-L1cache.sm (fea29fc045ee)
  *   src/mem/protocol/MESI_Two_Level-L2cache.sm (fea29fc045ee)
  *   src/mem/protocol/MESI_Two_Level-dir.sm (fea29fc045ee)
  *   src/mem/protocol/MESI_Two_Level-dma.sm (fea29fc045ee)
  *   src/mem/protocol/RubySlicc_Exports.sm (fea29fc045ee)
  *   src/mem/slicc/ast/DeclListAST.py (fea29fc045ee)
  *   src/mem/slicc/ast/MachineAST.py (fea29fc045ee)
  *   src/mem/slicc/parser.py (fea29fc045ee)
  *   src/mem/slicc/symbols/SymbolTable.py (fea29fc045ee)
  *   src/mem/slicc/symbols/Type.py (fea29fc045ee)

View Diffhttp://reviews.gem5.org/r/2551/diff/


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

Re: [gem5-dev] Review Request 2551: ruby: slicc: have a static MachineType

[Beckmann, Brad]

Oops I should have said the patch introduces the MachineType enum, rather than 
removes it.  Please disregard the third paragraph in my prior email.

Yes, this patch helps with collecting stats that are protocol specific.  
Eventually we need to move the MachineType underneath the RubySystem.  I think 
this patch will help in that effort.

Brad



From: Beckmann, Brad
Sent: Friday, May 08, 2015 1:04 PM
To: 'Jason Power'; gem5 Developer List; Nilay Vaish
Subject: RE: [gem5-dev] Review Request 2551: ruby: slicc: have a static 
MachineType

First off, I was also seeing the private patch error.  I think Nilay changed 
the access permissions on that particular patch for a moment.  It should now be 
accessible again.

Let’s be clear, the MachineType object and its associated functions were static 
before this change.  That is a big problem that we will need to fix soon.  
You’ll see more from Brandon Potter on this soon.

I believe this patch actually is a step in the right direction as far as 
removing the static dependencies on MachineType.  Before this patch, the 
MachineType enum needed to be inclusive of all possible machine types created 
by the protocols.  Thus the RubySlicc_Export.sm file was a global file that 
needed to be modified by every protocol that introduced a new machine name.  
That dependency goes away with this change.

Yes, we do have patches in the pipeline that implement non-CPU cache 
controllers.  They depend on this patch being checked in.

Brad




From: Jason Power [mailto:power...@gmail.com]
Sent: Friday, May 08, 2015 11:57 AM
To: gem5 Developer List; Beckmann, Brad; Nilay Vaish
Subject: Re: [gem5-dev] Review Request 2551: ruby: slicc: have a static 
MachineType

Hi Brad,
I personally would not like to see this patch pushed as it is. It breaks our 
workflow for gem5-gpu. Also, it seems to me that making the MachineTypes static 
is a step backwards. It's already hard with Ruby to create a protocol that 
isn't a traditional CPU-oriented protocol, and by not allowing new machine 
types (easily) it makes it that much harder.

I have to admit it's been a long time since I looked at this patch, and 
unfortunately I can't right now because I'm getting an error with reviewboard 
This review request is private. You must be a requested reviewer, either 
directly or on a requested group, and have permission to access the repository 
in order to view this review request. Strange.

Brad, do you have any patches in the (very near) pipeline that will allow for 
more MachineTypes than just the basic CPU-oriented caches? I suppose I could be 
convinced to modify our protocols once, but I really don't want to have to 
change them with every gem5 update more than we already do.

Overall, I can't remember what problem this patch originally solves. Was the 
problem that the Ruby stats depended on a static number of 
(Generic)MachineTypes? If this is the problem this patch solves, wouldn't it be 
better to instead make the stats accept dynamic MachineTypes?

If the rest of the community disagrees with me and wants this patch as is, we 
can deal here at gem5-gpu. I would just much rather keep the changes we have to 
the mainline gem5 minimal as merges are already pretty hellish as it is.

Thanks,
Jason

On Fri, May 8, 2015 at 12:07 PM Beckmann, Brad 
brad.beckm...@amd.commailto:brad.beckm...@amd.com wrote:
Hi Nilay,

Can you check this patch and the previous patch (review 2550) in the repo?  We 
will be posting a series of patches next week and they depend on these two 
patches.

Thanks,

Brad



From: Brad Beckmann 
[mailto:nore...@reviews.gem5.orgmailto:nore...@reviews.gem5.org] On Behalf Of 
Beckmann, Brad
Sent: Monday, April 27, 2015 3:30 PM
To: Nilay Vaish; Beckmann, Brad; Default
Subject: Re: Review Request 2551: ruby: slicc: have a static MachineType

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



Ship it!

Ship It!


- Brad Beckmann


On December 4th, 2014, 6:08 p.m. UTC, Nilay Vaish wrote:
Review request for Default.
By Nilay Vaish.

Updated Dec. 4, 2014, 6:08 p.m.
Repository: gem5
Description

Changeset 10594:b25131489b95

---

ruby: slicc: have a static MachineType

This patch moves from a dynamically defined MachineType to a statically

defined one.  The need for this patch was felt since a dynamically defined

type prevents us from having types for which no machine definition may

exist.



The following changes have been made:

i. each machine definition now uses a type from the MachineType enumeration

instead of any random identifier.  This required changing the grammar and the

*.sm files.



ii. MachineType enumeration defined statically in RubySlicc_Exports.sm.


Diffs

  *   src/mem/protocol/MESI_Two_Level-L1cache.sm (fea29fc045ee)
  *   src/mem/protocol/MESI_Two_Level-L2cache.sm (fea29fc045ee)
  *   src/mem/protocol/MESI_Two_Level-dir.sm (fea29fc045ee)
  *   src/mem/protocol/MESI_Two_Level-dma.sm (fea29fc045ee

Re: [gem5-dev] Review Request 2551: ruby: slicc: have a static MachineType

[Beckmann, Brad]

For approximately 10 years, Ruby had a statically defined set of generic 
machine types which allowed protocol specific profiling.  Unfortunately that 
support was taken out and as a result, one cannot breakdown latency based on 
the MachineType that satisfied the request.  Personally, I believe this is one 
of the most valuable sets of information that Ruby can provide.  I’m surprised 
this patch is receiving this much resistance.  This isn’t much different than 
how Ruby used to work.

Brad


From: Joel Hestness [mailto:jthestn...@gmail.com]
Sent: Friday, May 08, 2015 1:48 PM
To: gem5 Developer List
Cc: Beckmann, Brad; Nilay Vaish
Subject: Re: [gem5-dev] Review Request 2551: ruby: slicc: have a static 
MachineType

Hi guys,
  I have some input here:
   1) First and foremost: If we decide the direction of this patch is alright, 
it should *NOT* ship as is, because it only fixes the machine type for the 
MESI_Two_Level protocol. The rest of the protocol files need to be updated 
(unless I'm overlooking something).

   2) I agree with Jason that we shouldn't have a statically defined set of 
machine types. The way that Ruby generates controllers is very flexible so that 
adding or swapping out controllers is simple. You would no longer be able to do 
this without the MachineType enumeration containing a superset of all the 
controllers that various protocols include.

   3) I've read this request each time discussion has come up, and I still 
don't understand the need for it. As is, the patch's aim and the 
protocol-specific stats problem are not adequately described for this patch to 
make sense. I'd strongly prefer that the patch description be rewritten so that 
it is much clearer what is meant by prevents us from having types for which no 
machine definition may exist. I'd also strongly prefer a more detailed 
description of the problem with protocol-specific stats. These are a must to 
offer an informed patch review.

  Joel



On Fri, May 8, 2015 at 3:19 PM, Jason Power 
power...@gmail.commailto:power...@gmail.com wrote:
Hi Brad,

Thanks for the reply. I agree that MachineType needs to be fixed so it can
work better with stat collection. However, I disagree that this patch is a
step in the right direction. As you say, with this patch any protocol that
wants to add a new machine type will have to modify RubySlicc_Export.sm,
and this is exactly what I want to avoid. The current state of Ruby is that
I can add new machines without having to change anything in the mainline
gem5 repo. I strongly want to keep it this way.

If you have future patches that can restore this feature, and do not
require new machines to be declared *a priori* in RubySlicc_Export.sm,
that's great. But I would much prefer just jumping to those patches, and
not going through this patch as it is.

The key feature that I want is to be able to create a new machine for some
protocol without having to export its name globally to all protocols. If we
go with this patch, then anyone who ever creates a new machine type will
have to declare it in RubySlicc_Export.sm. That means either in the gem5
repo we'll have all sorts of machine types that only one (or a few) people
are using, or everyone who wants to use a new machine type will have to
have yet another patch in their patch queue.

However, I will admit this isn't certainly the end of the world if this
patch goes in. If you guys really need it, we can just add another patch to
our internal patch queue for gem5-gpu. I'm mostly pushing back here because
of all the times that I didn't push back on similarly (seemingly) small
changes to Ruby ;).

Cheers,
Jason

On Fri, May 8, 2015 at 3:10 PM Beckmann, Brad 
brad.beckm...@amd.commailto:brad.beckm...@amd.com wrote:

  Oops I should have said the patch introduces the MachineType enum,
 rather than removes it.  Please disregard the third paragraph in my prior
 email.



 Yes, this patch helps with collecting stats that are protocol specific.
 Eventually we need to move the MachineType underneath the RubySystem.  I
 think this patch will help in that effort.



 Brad







 *From:* Beckmann, Brad
 *Sent:* Friday, May 08, 2015 1:04 PM
 *To:* 'Jason Power'; gem5 Developer List; Nilay Vaish
 *Subject:* RE: [gem5-dev] Review Request 2551: ruby: slicc: have a static
 MachineType



 First off, I was also seeing the private patch error.  I think Nilay
 changed the access permissions on that particular patch for a moment.  It
 should now be accessible again.



 Let’s be clear, the MachineType object and its associated functions were
 static before this change.  That is a big problem that we will need to fix
 soon.  You’ll see more from Brandon Potter on this soon.



 I believe this patch actually is a step in the right direction as far as
 removing the static dependencies on MachineType.  Before this patch, the
 MachineType enum needed to be inclusive of all possible machine types
 created by the protocols.  Thus the RubySlicc_Export.sm file

Re: [gem5-dev] changeset in gem5: ruby: route all packets through ruby port

[Beckmann, Brad]

Hi Nilay,

In this changeset, you added the memSlavePort to RubyPort.  Please note, the 
variable RubyPort::memSlavePort is separate from the vector of MemSlavePorts 
RubyPort::slave_ports.  I cannot find any configuration that actually 
instantiates or uses the former mem_slave_port.  Can we remove that variable 
from RubyPort so that it is not confused with the real slave_ports?

Thanks,

Brad



-Original Message-
From: gem5-dev-boun...@gem5.org [mailto:gem5-dev-boun...@gem5.org] On Behalf Of 
Nilay Vaish
Sent: Sunday, February 23, 2014 5:17 PM
To: gem5-...@m5sim.org
Subject: [gem5-dev] changeset in gem5: ruby: route all packets through ruby port

changeset 4eec7bdde5b0 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=4eec7bdde5b0
description:
ruby: route all packets through ruby port
Currently, the interrupt controller in x86 is connected to the io bus
directly.  Therefore the packets between the io devices and the 
interrupt
controller do not go through ruby.  This patch changes ruby port so that
these packets arrive at the ruby port first, which then routes them to 
their
destination.  Note that the patch does not make these packets go 
through the
ruby network.  That would happen in a subsequent patch.

diffstat:

 configs/example/ruby_fs.py |9 +-
 configs/ruby/MESI_Two_Level.py |4 +-
 src/mem/ruby/system/RubyPort.cc|  193 ++--
 src/mem/ruby/system/RubyPort.hh|   82 ++---
 src/mem/ruby/system/Sequencer.py   |   12 +-
 tests/configs/pc-simple-timing-ruby.py |6 +-
 6 files changed, 216 insertions(+), 90 deletions(-)

diffs (truncated from 610 to 300 lines):

diff -r bc3126a05a7f -r 4eec7bdde5b0 configs/example/ruby_fs.py
--- a/configs/example/ruby_fs.pySun Feb 23 19:16:16 2014 -0600
+++ b/configs/example/ruby_fs.pySun Feb 23 19:16:16 2014 -0600
@@ -122,14 +122,17 @@
 cpu.clk_domain = system.cpu_clk_domain
 cpu.createThreads()
 cpu.createInterruptController()
+
 cpu.icache_port = system.ruby._cpu_ruby_ports[i].slave
 cpu.dcache_port = system.ruby._cpu_ruby_ports[i].slave
+
 if buildEnv['TARGET_ISA'] == x86:
 cpu.itb.walker.port = system.ruby._cpu_ruby_ports[i].slave
 cpu.dtb.walker.port = system.ruby._cpu_ruby_ports[i].slave
-cpu.interrupts.pio = system.piobus.master
-cpu.interrupts.int_master = system.piobus.slave
-cpu.interrupts.int_slave = system.piobus.master
+
+cpu.interrupts.pio = system.ruby._cpu_ruby_ports[i].master
+cpu.interrupts.int_master = system.ruby._cpu_ruby_ports[i].slave
+cpu.interrupts.int_slave = 
+ system.ruby._cpu_ruby_ports[i].master
 
 system.ruby._cpu_ruby_ports[i].access_phys_mem = True
 
diff -r bc3126a05a7f -r 4eec7bdde5b0 configs/ruby/MESI_Two_Level.py
--- a/configs/ruby/MESI_Two_Level.pySun Feb 23 19:16:16 2014 -0600
+++ b/configs/ruby/MESI_Two_Level.pySun Feb 23 19:16:16 2014 -0600
@@ -106,7 +106,9 @@
 l1_cntrl.sequencer = cpu_seq
 
 if piobus != None:
-cpu_seq.pio_port = piobus.slave
+cpu_seq.pio_master_port = piobus.slave
+cpu_seq.mem_master_port = piobus.slave
+cpu_seq.pio_slave_port = piobus.master
 
 exec(ruby_system.l1_cntrl%d = l1_cntrl % i)
 
diff -r bc3126a05a7f -r 4eec7bdde5b0 src/mem/ruby/system/RubyPort.cc
--- a/src/mem/ruby/system/RubyPort.cc   Sun Feb 23 19:16:16 2014 -0600
+++ b/src/mem/ruby/system/RubyPort.cc   Sun Feb 23 19:16:16 2014 -0600
@@ -50,25 +50,28 @@
 
 RubyPort::RubyPort(const Params *p)
 : MemObject(p), m_version(p-version), m_controller(NULL),
-  m_mandatory_q_ptr(NULL),
-  pio_port(csprintf(%s-pio-port, name()), this),
-  m_usingRubyTester(p-using_ruby_tester),
-  drainManager(NULL), ruby_system(p-ruby_system), system(p-system),
+  m_mandatory_q_ptr(NULL), m_usingRubyTester(p-using_ruby_tester),
+  pioMasterPort(csprintf(%s.pio-master-port, name()), this),
+  pioSlavePort(csprintf(%s.pio-slave-port, name()), this),
+  memMasterPort(csprintf(%s.mem-master-port, name()), this),
+  memSlavePort(csprintf(%s-mem-slave-port, name()), this,
+  p-ruby_system, p-access_phys_mem, -1),
+  gotAddrRanges(p-port_master_connection_count), drainManager(NULL),
+  ruby_system(p-ruby_system), system(p-system),
   access_phys_mem(p-access_phys_mem)
 {
 assert(m_version != -1);
 
 // create the slave ports based on the number of connected ports
 for (size_t i = 0; i  p-port_slave_connection_count; ++i) {
-slave_ports.push_back(new M5Port(csprintf(%s-slave%d, name(), i),
- this, ruby_system,
- access_phys_mem, i));
+slave_ports.push_back(new MemSlavePort(csprintf(%s.slave%d, name(),
+i), this, ruby_system, access_phys_mem, i));

Re: [gem5-dev] Review Request 2749: cpu: testers: rubytest: fix the test

[Beckmann, Brad]

Replies below:

-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Nilay Vaish
Sent: Thursday, April 30, 2015 8:20 AM
To: gem5 Developer List
Subject: Re: [gem5-dev] Review Request 2749: cpu: testers: rubytest: fix the 
test

On Wed, 29 Apr 2015, Beckmann, Brad wrote:

 My main objection to the change is that it is not worth the time.  It 
 is taking a sledgehammer to a bug that only requires a minor tweak.  
 There is a lot of downstream code that will be impacted by a change 
 that doesn't provide any real benefit.  To do what you want the right 
 way, would require making the CheckTable and RubyTesters separate 
 SimObjects and then instantiating them appropriately.  Why go through 
 all that trouble?

I am willing to go through all the trouble because I am confident that the 
right way is to have multiple testers and not one single tester.

Anyways, there are two questions that come to my mind here.

First, let's for an instant assume that we do not want to change ruby tester's 
c++ code.  How do you propose we fix the current bug?  Since you have not 
posted any code, I am discussing what I think would be done.  We will have to 
make each protocol configuration file understand that it cannot assume that the 
number of cpu objects is same as options.num_cpus and do something different 
when the two quantities are unequal.  Do we want to put that down as a policy?  
Don't you think this renders the option meaningless?

[BB] This is where I don't fully understand the bug you are encountering.  The 
number of cpus is different than the number of testers.  The number of cpus 
should impact the number of m5 ports provided by the tester, not the number of 
testers.  That is how the tester has worked in the past.  If the current 
configurations don't support that, then they need to be fixed.

Second, this question is more general and should be discussed more widely. 
When is a change deemed as 'impacting downstream code'? And what should be our 
policy for such changes?

[BB] When new features are added to the code, then one should expect that 
downstream code should be impacted.  However, a simple problem in configuration 
should not require one to change how ruby testers are architected.  More ruby 
testers exist than what is currently available in the public tree.

 What separate code are you concerned about?  The specific code to handle 
 the tester in Ruby (C++) has nothing to do with whether there is one 
 RubyTester or multiple RubyTesters.


May be it has nothing to do with single or multiple testers.  But you 
agree that we have code where we behave differently if a tester is 
running.  And I do not want such code to proliferate.

[BB] I think the fundamental problem there is the too simplistic RubyPort 
interface.  There are several problems that could be fixed if we allowed a 
richer set of information to be passed between Ruby and the packet generators 
(CPUs/testers/GPUs/etc.).


--
Nilay
___
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 2749: cpu: testers: rubytest: fix the test

[Beckmann, Brad]

My main objection to the change is that it is not worth the time.  It is taking 
a sledgehammer to a bug that only requires a minor tweak.  There is a lot of 
downstream code that will be impacted by a change that doesn't provide any real 
benefit.  To do what you want the right way, would require making the 
CheckTable and RubyTesters separate SimObjects and then instantiating them 
appropriately.  Why go through all that trouble?

What separate code are you concerned about?  The specific code to handle the 
tester in Ruby (C++) has nothing to do with whether there is one RubyTester or 
multiple RubyTesters.

Brad

 

-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Nilay Vaish
Sent: Wednesday, April 29, 2015 1:35 PM
To: gem5 Developer List
Subject: Re: [gem5-dev] Review Request 2749: cpu: testers: rubytest: fix the 
test

On Tue, 28 Apr 2015, Beckmann, Brad wrote:

 The tester has always been a single object (since 1999!).  The tester 
 works in a coordinated fashion to instigate races.  It does not 
 operate as separate independent objects.


Brad, even if it has been a single object for a long time, I still believe it 
is not the right way.  If we have multiple objects, we should still be able to 
make them work in a coordinated fashion by letting them share some portion of 
memory.  I did this by marking the CheckTable static, but I am willing to make 
it common to every tester object in a different fashion. 
Can you explain what may prevent us from coordinating multiple tester objects?

Again, I do not want to create separate code for testing and for simulation.  
There are several places in ruby where we do this and I think we should do away 
with them, instead of further spreading this approach.


--
Nilay
___
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 2749: cpu: testers: rubytest: fix the test

[Beckmann, Brad]

The tester has always been a single object (since 1999!).  The tester works in 
a coordinated fashion to instigate races.  It does not operate as separate 
independent objects.

As for Andreas's question, one can certainly try to use the ruby tester with 
the classic memory model.  It does not need to be Ruby specific, but it is 
quite powerful.

Brad



-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Nilay Vaish
Sent: Tuesday, April 28, 2015 11:50 AM
To: gem5 Developer List
Subject: Re: [gem5-dev] Review Request 2749: cpu: testers: rubytest: fix the 
test

On Mon, 27 Apr 2015, Steve Reinhardt wrote:

 I appreciate Nilay's desire to not have the tester configuration 
 diverge from the simulation configuration. However, the general 
 impression I get here is that we're making the C++ more complicated in 
 order to avoid changes to the Python. Given that the point of putting 
 the configuration in python was to enable additional flexibility, this 
 direction (at least
 superficially) seems completely backwards.

 If we want to have common code that sets up Ruby configurations 
 independent of whether it will be supporting various objects 
 representing compute devices (CPUs/GPUs/whatever) or various ports on 
 a single tester object, then IMO the right approach is to find a way 
 to make the Python more modular, not to do unnatural things in the C++.

Why have a single tester object?

--
Nilay
___
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: dma sequencer: remove RubyPort as paren...

[Beckmann, Brad via gem5-dev]

Hi Nilay,

Did you consider this patch when you added the backing store back to Ruby?  The 
following lines in DMASequencer::MemSlavePort::hitCallback(PacketPtr pkt) 
initially updated the backing store, but I believe they were removed in a later 
patch (7a3ad4b09ce4).

+if (accessPhysMem) {
+DMASequencer *seq = static_castDMASequencer *(owner);
+seq-system-getPhysMem().access(pkt);
+} else if (needsResponse) {
+pkt-makeResponse();
+}
+

Is it as simple as adding those 6 lines back into the DMA sequencer?  Are there 
other issues we should consider?

Thanks,

Brad



-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Nilay Vaish via 
gem5-dev
Sent: Thursday, November 06, 2014 3:37 AM
To: gem5-...@m5sim.org
Subject: [gem5-dev] changeset in gem5: ruby: dma sequencer: remove RubyPort as 
paren...

changeset 30e3715c9405 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=30e3715c9405
description:
ruby: dma sequencer: remove RubyPort as parent class
As of now DMASequencer inherits from the RubyPort class.  But the code 
in
RubyPort class is heavily tailored for the CPU Sequencer.  There are 
parts of
the code that are not required at all for the DMA sequencer.  Moreover, 
the
next patch uses the dma sequencer for carrying out memory accesses for 
all the
io devices.  Hence, it is better to have a leaner dma sequencer.

diffstat:

 src/mem/ruby/system/DMASequencer.cc |  195 +++-
 src/mem/ruby/system/DMASequencer.hh |   75 +-
 src/mem/ruby/system/Sequencer.py|   13 +-
 3 files changed, 274 insertions(+), 9 deletions(-)

diffs (truncated from 374 to 300 lines):

diff -r ba51f8572571 -r 30e3715c9405 src/mem/ruby/system/DMASequencer.cc
--- a/src/mem/ruby/system/DMASequencer.cc   Mon Nov 03 10:14:42 2014 -0600
+++ b/src/mem/ruby/system/DMASequencer.cc   Thu Nov 06 00:55:09 2014 -0600
@@ -28,26 +28,212 @@
 
 #include memory
 
+#include debug/Config.hh
+#include debug/Drain.hh
 #include debug/RubyDma.hh
 #include debug/RubyStats.hh
 #include mem/protocol/SequencerMsg.hh
-#include mem/protocol/SequencerRequestType.hh
 #include mem/ruby/system/DMASequencer.hh
 #include mem/ruby/system/System.hh
+#include sim/system.hh
 
 DMASequencer::DMASequencer(const Params *p)
-: RubyPort(p)
+: MemObject(p), m_version(p-version), m_controller(NULL),
+  m_mandatory_q_ptr(NULL), m_usingRubyTester(p-using_ruby_tester),
+  slave_port(csprintf(%s.slave, name()), this, access_phys_mem, 0),
+  drainManager(NULL), system(p-system), retry(false),
+  access_phys_mem(p-access_phys_mem)
 {
+assert(m_version != -1);
 }
 
 void
 DMASequencer::init()
 {
-RubyPort::init();
+MemObject::init();
+assert(m_controller != NULL);
+m_mandatory_q_ptr = m_controller-getMandatoryQueue();
+m_mandatory_q_ptr-setSender(this);
 m_is_busy = false;
 m_data_block_mask = ~ (~0  RubySystem::getBlockSizeBits());  }
 
+BaseSlavePort 
+DMASequencer::getSlavePort(const std::string if_name, PortID idx) {
+// used by the CPUs to connect the caches to the interconnect, and
+// for the x86 case also the interrupt master
+if (if_name != slave) {
+// pass it along to our super class
+return MemObject::getSlavePort(if_name, idx);
+} else {
+return slave_port;
+}
+}
+
+DMASequencer::MemSlavePort::MemSlavePort(const std::string _name,
+DMASequencer *_port, bool _access_phys_mem, PortID id)
+: QueuedSlavePort(_name, _port, queue, id), queue(*_port, *this),
+  access_phys_mem(_access_phys_mem) {
+DPRINTF(RubyDma, Created slave memport on ruby sequencer %s\n, 
+_name); }
+
+bool
+DMASequencer::MemSlavePort::recvTimingReq(PacketPtr pkt) {
+DPRINTF(RubyDma, Timing request for address %#x on port %d\n,
+pkt-getAddr(), id);
+DMASequencer *seq = static_castDMASequencer *(owner);
+
+if (pkt-memInhibitAsserted())
+panic(DMASequencer should never see an inhibited request\n);
+
+assert(isPhysMemAddress(pkt-getAddr()));
+assert(Address(pkt-getAddr()).getOffset() + pkt-getSize() =
+   RubySystem::getBlockSizeBytes());
+
+// Submit the ruby request
+RequestStatus requestStatus = seq-makeRequest(pkt);
+
+// If the request successfully issued then we should return true.
+// Otherwise, we need to tell the port to retry at a later point
+// and return false.
+if (requestStatus == RequestStatus_Issued) {
+DPRINTF(RubyDma, Request %s 0x%x issued\n, pkt-cmdString(),
+pkt-getAddr());
+return true;
+}
+
+// Unless one is using the ruby tester, record the stalled M5 port for
+// later retry when the sequencer becomes free.
+if (!seq-m_usingRubyTester) {
+seq-retry = true;
+}
+
+DPRINTF(RubyDma, Request for address %#x did not issued because %s\n,
+

Re: [gem5-dev] changeset in gem5: ruby: dma sequencer: remove RubyPort as paren...

[Beckmann, Brad via gem5-dev]

I should clarify.  Is the simple way of supporting the backing store and DMA is 
adding those 6 lines back to the DMA sequencer?

Also have you considered the case for multi-cache block DMA and updating the 
backing store?  It appears that only the final cache block of a large 
multi-cache block write will even call 
DMASequencer::MemSlavePort::hitCallback().  How can we get the other DMA writes 
to update the backing store?

Thanks,

Brad



-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Beckmann, Brad 
via gem5-dev
Sent: Monday, February 09, 2015 4:58 PM
To: gem5 Developer List; gem5-...@m5sim.org
Subject: Re: [gem5-dev] changeset in gem5: ruby: dma sequencer: remove RubyPort 
as paren...

Hi Nilay,

Did you consider this patch when you added the backing store back to Ruby?  The 
following lines in DMASequencer::MemSlavePort::hitCallback(PacketPtr pkt) 
initially updated the backing store, but I believe they were removed in a later 
patch (7a3ad4b09ce4).

+if (accessPhysMem) {
+DMASequencer *seq = static_castDMASequencer *(owner);
+seq-system-getPhysMem().access(pkt);
+} else if (needsResponse) {
+pkt-makeResponse();
+}
+

Is it as simple as adding those 6 lines back into the DMA sequencer?  Are there 
other issues we should consider?

Thanks,

Brad



-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Nilay Vaish via 
gem5-dev
Sent: Thursday, November 06, 2014 3:37 AM
To: gem5-...@m5sim.org
Subject: [gem5-dev] changeset in gem5: ruby: dma sequencer: remove RubyPort as 
paren...

changeset 30e3715c9405 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=30e3715c9405
description:
ruby: dma sequencer: remove RubyPort as parent class
As of now DMASequencer inherits from the RubyPort class.  But the code 
in
RubyPort class is heavily tailored for the CPU Sequencer.  There are 
parts of
the code that are not required at all for the DMA sequencer.  Moreover, 
the
next patch uses the dma sequencer for carrying out memory accesses for 
all the
io devices.  Hence, it is better to have a leaner dma sequencer.

diffstat:

 src/mem/ruby/system/DMASequencer.cc |  195 +++-
 src/mem/ruby/system/DMASequencer.hh |   75 +-
 src/mem/ruby/system/Sequencer.py|   13 +-
 3 files changed, 274 insertions(+), 9 deletions(-)

diffs (truncated from 374 to 300 lines):

diff -r ba51f8572571 -r 30e3715c9405 src/mem/ruby/system/DMASequencer.cc
--- a/src/mem/ruby/system/DMASequencer.cc   Mon Nov 03 10:14:42 2014 -0600
+++ b/src/mem/ruby/system/DMASequencer.cc   Thu Nov 06 00:55:09 2014 -0600
@@ -28,26 +28,212 @@
 
 #include memory
 
+#include debug/Config.hh
+#include debug/Drain.hh
 #include debug/RubyDma.hh
 #include debug/RubyStats.hh
 #include mem/protocol/SequencerMsg.hh
-#include mem/protocol/SequencerRequestType.hh
 #include mem/ruby/system/DMASequencer.hh
 #include mem/ruby/system/System.hh
+#include sim/system.hh
 
 DMASequencer::DMASequencer(const Params *p)
-: RubyPort(p)
+: MemObject(p), m_version(p-version), m_controller(NULL),
+  m_mandatory_q_ptr(NULL), m_usingRubyTester(p-using_ruby_tester),
+  slave_port(csprintf(%s.slave, name()), this, access_phys_mem, 0),
+  drainManager(NULL), system(p-system), retry(false),
+  access_phys_mem(p-access_phys_mem)
 {
+assert(m_version != -1);
 }
 
 void
 DMASequencer::init()
 {
-RubyPort::init();
+MemObject::init();
+assert(m_controller != NULL);
+m_mandatory_q_ptr = m_controller-getMandatoryQueue();
+m_mandatory_q_ptr-setSender(this);
 m_is_busy = false;
 m_data_block_mask = ~ (~0  RubySystem::getBlockSizeBits());  }
 
+BaseSlavePort 
+DMASequencer::getSlavePort(const std::string if_name, PortID idx) {
+// used by the CPUs to connect the caches to the interconnect, and
+// for the x86 case also the interrupt master
+if (if_name != slave) {
+// pass it along to our super class
+return MemObject::getSlavePort(if_name, idx);
+} else {
+return slave_port;
+}
+}
+
+DMASequencer::MemSlavePort::MemSlavePort(const std::string _name,
+DMASequencer *_port, bool _access_phys_mem, PortID id)
+: QueuedSlavePort(_name, _port, queue, id), queue(*_port, *this),
+  access_phys_mem(_access_phys_mem) {
+DPRINTF(RubyDma, Created slave memport on ruby sequencer %s\n, 
+_name); }
+
+bool
+DMASequencer::MemSlavePort::recvTimingReq(PacketPtr pkt) {
+DPRINTF(RubyDma, Timing request for address %#x on port %d\n,
+pkt-getAddr(), id);
+DMASequencer *seq = static_castDMASequencer *(owner);
+
+if (pkt-memInhibitAsserted())
+panic(DMASequencer should never see an inhibited request\n);
+
+assert(isPhysMemAddress(pkt-getAddr()));
+assert(Address(pkt-getAddr()).getOffset() + pkt-getSize() =
+   RubySystem

Re: [gem5-dev] changeset in gem5: ruby: dma sequencer: remove RubyPort as paren...

[Beckmann, Brad via gem5-dev]

Thanks Jason.  I didn't notice your patch until after I sent out my email.  It 
looks like we are encountering the same problem.

I'm a bit concern that your patch doesn't modify DMASequencer::ackCallback(), 
thus it doesn't get us very close to correctly supporting multi-cache block 
dma.  It seems like we need a fundamental different approach that separates 
updating the backing store from sending the response packet to the dma device.

Brad



-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Jason Power via 
gem5-dev
Sent: Monday, February 09, 2015 6:06 PM
To: gem5 Developer List; gem5-...@m5sim.org
Subject: Re: [gem5-dev] changeset in gem5: ruby: dma sequencer: remove RubyPort 
as paren...

Hey Brad,

I think this change is in my patch to fix the backing store. It's on 
reviewboard now.
http://reviews.gem5.org/r/2627/

I'm not sure if that patch supports multi cache block DMA, but it's definitely 
a step in the right direction.

There's also another patch for unaligned DMA.
http://reviews.gem5.org/r/2653/. That patch was required for us to get our copy 
engine working.



Let me know if you have any feedback or if it solves your problem.

Cheers,


Jason

On Mon Feb 09 2015 at 7:03:54 PM Beckmann, Brad via gem5-dev  
gem5-dev@gem5.org wrote:

I should clarify.  Is the simple way of supporting the backing store and DMA is 
adding those 6 lines back to the DMA sequencer?

Also have you considered the case for multi-cache block DMA and updating the 
backing store?  It appears that only the final cache block of a large 
multi-cache block write will even call 
DMASequencer::MemSlavePort::hitCallback().  How can we get the other DMA writes 
to update the backing store?

Thanks,

Brad

-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Beckmann, Brad 
via gem5-dev
Sent: Monday, February 09, 2015 4:58 PM
To: gem5 Developer List; gem5-...@m5sim.org
Subject: Re: [gem5-dev] changeset in gem5: ruby: dma sequencer: remove RubyPort 
as paren...

Hi Nilay,

Did you consider this patch when you added the backing store back to Ruby?
The following lines in DMASequencer::MemSlavePort::hitCallback(PacketPtr
pkt) initially updated the backing store, but I believe they were removed in a 
later patch (7a3ad4b09ce4).

+if (accessPhysMem) {
+DMASequencer *seq = static_castDMASequencer *(owner);
+seq-system-getPhysMem().access(pkt);
+} else if (needsResponse) {
+pkt-makeResponse();
+}
+

Is it as simple as adding those 6 lines back into the DMA sequencer?  Are there 
other issues we should consider?

Thanks,

Brad

-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Nilay Vaish via 
gem5-dev
Sent: Thursday, November 06, 2014 3:37 AM
To: gem5-...@m5sim.org
Subject: [gem5-dev] changeset in gem5: ruby: dma sequencer: remove RubyPort as 
paren...

changeset 30e3715c9405 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=30e3715c9405
description:
ruby: dma sequencer: remove RubyPort as parent class
As of now DMASequencer inherits from the RubyPort class.  But the code 
in
RubyPort class is heavily tailored for the CPU Sequencer.  There are 
parts of
the code that are not required at all for the DMA sequencer.
Moreover, the
next patch uses the dma sequencer for carrying out memory accesses for 
all the
io devices.  Hence, it is better to have a leaner dma sequencer.

diffstat:

 src/mem/ruby/system/DMASequencer.cc |  195
+++-
 src/mem/ruby/system/DMASequencer.hh |   75 +-
 src/mem/ruby/system/Sequencer.py|   13 +-
 3 files changed, 274 insertions(+), 9 deletions(-)

diffs (truncated from 374 to 300 lines):

diff -r ba51f8572571 -r 30e3715c9405 src/mem/ruby/system/DMASequencer.cc
--- a/src/mem/ruby/system/DMASequencer.cc   Mon Nov 03 10:14:42 2014
-0600
+++ b/src/mem/ruby/system/DMASequencer.cc   Thu Nov 06 00:55:09 2014
-0600
@@ -28,26 +28,212 @@

 #include memory

+#include debug/Config.hh
+#include debug/Drain.hh
 #include debug/RubyDma.hh
 #include debug/RubyStats.hh
 #include mem/protocol/SequencerMsg.hh
-#include mem/protocol/SequencerRequestType.hh
 #include mem/ruby/system/DMASequencer.hh
 #include mem/ruby/system/System.hh
+#include sim/system.hh

 DMASequencer::DMASequencer(const Params *p)
-: RubyPort(p)
+: MemObject(p), m_version(p-version), m_controller(NULL),
+  m_mandatory_q_ptr(NULL), m_usingRubyTester(p-using_ruby_tester),
+  slave_port(csprintf(%s.slave, name()), this, access_phys_mem, 0),
+  drainManager(NULL), system(p-system), retry(false),
+  access_phys_mem(p-access_phys_mem)
 {
+assert(m_version != -1);
 }

 void
 DMASequencer::init()
 {
-RubyPort::init();
+MemObject::init();
+assert(m_controller != NULL);
+m_mandatory_q_ptr = m_controller-getMandatoryQueue();
+m_mandatory_q_ptr-setSender

Re: [gem5-dev] changeset in gem5: cpu: Fix cache blocked load behavior in o3 cpu

[Beckmann, Brad via gem5-dev]

Thanks Mitch for the quick reply.

While assuming stores are only sent after commit is true for the current O3 
model, aggressive out-of-order processors send store addresses to the memory 
system as soon as they are available (i.e. speculatively).  We actually have a 
patch that provides such a capability, but I'm having a tough time figuring out 
how to merge it with your change.  Any suggestions you may have would be very 
much appreciated.

Thanks,

Brad



-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Mitch Hayenga 
via gem5-dev
Sent: Friday, January 30, 2015 9:34 AM
To: gem5 Developer List
Cc: gem5-...@m5sim.org
Subject: Re: [gem5-dev] changeset in gem5: cpu: Fix cache blocked load behavior 
in o3 cpu

Hi,

Stores should be fine since they are only sent to the memory system after
commit.   The relevant functions to look at are
sendStore, recvRetry, and writebackStores in lsq_unit_impl.hh.

Basically, if a store gets blocked the core just waits until it gets a retry.  
Since stores are sent in-order from the SQ to the memory system, that queue 
just waits.  The stores are never removed from the SQ unless they succeed.

Loads were special in that they were effectively removed from the scheduler, 
even if they might fail.  Stores however always maintain their entries/order 
until they succeed.





On Thu, Jan 29, 2015 at 6:01 PM, Beckmann, Brad via gem5-dev  
gem5-dev@gem5.org wrote:

 Hi Mitch,

 Quick question regarding this patch.  Does this patch also handle 
 replaying stores once the cache becomes unblocked?  The changes and 
 comments appear to only handle loads, but it seems like stores could 
 have the same problem.

 Thanks,

 Brad



 -Original Message-
 From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Mitch 
 Hayenga via gem5-dev
 Sent: Wednesday, September 03, 2014 4:38 AM
 To: gem5-...@m5sim.org
 Subject: [gem5-dev] changeset in gem5: cpu: Fix cache blocked load 
 behavior in o3 cpu

 changeset 6be8945d226b in /z/repo/gem5
 details: http://repo.gem5.org/gem5?cmd=changeset;node=6be8945d226b
 description:
 cpu: Fix cache blocked load behavior in o3 cpu

 This patch fixes the load blocked/replay mechanism in the o3 cpu.
 Rather than
 flushing the entire pipeline, this patch replays loads once 
 the cache becomes
 unblocked.

 Additionally, deferred memory instructions (loads which had 
 conflicting stores),
 when replayed would not respect the number of functional units 
 (only respected
 issue width).  This patch also corrects that.

 Improvements over 20% have been observed on a microbenchmark 
 designed to
 exercise this behavior.

 diffstat:

  src/cpu/o3/iew.hh   |   13 +-
  src/cpu/o3/iew_impl.hh  |   57 ++
  src/cpu/o3/inst_queue.hh|   25 -
  src/cpu/o3/inst_queue_impl.hh   |   68 ++---
  src/cpu/o3/lsq.hh   |   27 +-
  src/cpu/o3/lsq_impl.hh  |   23 +---
  src/cpu/o3/lsq_unit.hh  |  198
 ---
  src/cpu/o3/lsq_unit_impl.hh |   40 ++-
  src/cpu/o3/mem_dep_unit.hh  |4 +-
  src/cpu/o3/mem_dep_unit_impl.hh |4 +-
  10 files changed, 203 insertions(+), 256 deletions(-)

 diffs (truncated from 846 to 300 lines):

 diff -r 1ba825974ee6 -r 6be8945d226b src/cpu/o3/iew.hh
 --- a/src/cpu/o3/iew.hh Wed Sep 03 07:42:38 2014 -0400
 +++ b/src/cpu/o3/iew.hh Wed Sep 03 07:42:39 2014 -0400
 @@ -1,5 +1,5 @@
  /*
 - * Copyright (c) 2010-2012 ARM Limited
 + * Copyright (c) 2010-2012, 2014 ARM Limited
   * All rights reserved
   *
   * The license below extends only to copyright in the software and 
 shall @@ -181,6 +181,12 @@
  /** Re-executes all rescheduled memory instructions. */
  void replayMemInst(DynInstPtr inst);

 +/** Moves memory instruction onto the list of cache blocked
 instructions */
 +void blockMemInst(DynInstPtr inst);
 +
 +/** Notifies that the cache has become unblocked */
 +void cacheUnblocked();
 +
  /** Sends an instruction to commit through the time buffer. */
  void instToCommit(DynInstPtr inst);

 @@ -233,11 +239,6 @@
   */
  void squashDueToMemOrder(DynInstPtr inst, ThreadID tid);

 -/** Sends commit proper information for a squash due to memory
 becoming
 - * blocked (younger issued instructions must be retried).
 - */
 -void squashDueToMemBlocked(DynInstPtr inst, ThreadID tid);
 -
  /** Sets Dispatch to blocked, and signals back to other stages to 
 block. */
  void block(ThreadID tid);

 diff -r 1ba825974ee6 -r 6be8945d226b src/cpu/o3/iew_impl.hh
 --- a/src/cpu/o3/iew_impl.hhWed Sep 03 07:42:38 2014 -0400
 +++ b/src/cpu/o3/iew_impl.hhWed Sep 03 07:42:39 2014 -0400
 @@ -530,29 +530,6 @@

  templateclass Impl
  void
 -DefaultIEWImpl::squashDueToMemBlocked(DynInstPtr inst, ThreadID tid) -{
 -DPRINTF(IEW, [tid:%i]: Memory blocked

Re: [gem5-dev] changeset in gem5: cpu: Fix cache blocked load behavior in o3 cpu

[Beckmann, Brad via gem5-dev]

Hi Mitch,

Quick question regarding this patch.  Does this patch also handle replaying 
stores once the cache becomes unblocked?  The changes and comments appear to 
only handle loads, but it seems like stores could have the same problem.

Thanks,

Brad



-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Mitch Hayenga 
via gem5-dev
Sent: Wednesday, September 03, 2014 4:38 AM
To: gem5-...@m5sim.org
Subject: [gem5-dev] changeset in gem5: cpu: Fix cache blocked load behavior in 
o3 cpu

changeset 6be8945d226b in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=6be8945d226b
description:
cpu: Fix cache blocked load behavior in o3 cpu

This patch fixes the load blocked/replay mechanism in the o3 cpu.  
Rather than
flushing the entire pipeline, this patch replays loads once the cache 
becomes
unblocked.

Additionally, deferred memory instructions (loads which had conflicting 
stores),
when replayed would not respect the number of functional units (only 
respected
issue width).  This patch also corrects that.

Improvements over 20% have been observed on a microbenchmark designed to
exercise this behavior.

diffstat:

 src/cpu/o3/iew.hh   |   13 +-
 src/cpu/o3/iew_impl.hh  |   57 ++
 src/cpu/o3/inst_queue.hh|   25 -
 src/cpu/o3/inst_queue_impl.hh   |   68 ++---
 src/cpu/o3/lsq.hh   |   27 +-
 src/cpu/o3/lsq_impl.hh  |   23 +---
 src/cpu/o3/lsq_unit.hh  |  198 ---
 src/cpu/o3/lsq_unit_impl.hh |   40 ++-
 src/cpu/o3/mem_dep_unit.hh  |4 +-
 src/cpu/o3/mem_dep_unit_impl.hh |4 +-
 10 files changed, 203 insertions(+), 256 deletions(-)

diffs (truncated from 846 to 300 lines):

diff -r 1ba825974ee6 -r 6be8945d226b src/cpu/o3/iew.hh
--- a/src/cpu/o3/iew.hh Wed Sep 03 07:42:38 2014 -0400
+++ b/src/cpu/o3/iew.hh Wed Sep 03 07:42:39 2014 -0400
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2010-2012 ARM Limited
+ * Copyright (c) 2010-2012, 2014 ARM Limited
  * All rights reserved
  *
  * The license below extends only to copyright in the software and shall @@ 
-181,6 +181,12 @@
 /** Re-executes all rescheduled memory instructions. */
 void replayMemInst(DynInstPtr inst);
 
+/** Moves memory instruction onto the list of cache blocked instructions */
+void blockMemInst(DynInstPtr inst);
+
+/** Notifies that the cache has become unblocked */
+void cacheUnblocked();
+
 /** Sends an instruction to commit through the time buffer. */
 void instToCommit(DynInstPtr inst);
 
@@ -233,11 +239,6 @@
  */
 void squashDueToMemOrder(DynInstPtr inst, ThreadID tid);
 
-/** Sends commit proper information for a squash due to memory becoming
- * blocked (younger issued instructions must be retried).
- */
-void squashDueToMemBlocked(DynInstPtr inst, ThreadID tid);
-
 /** Sets Dispatch to blocked, and signals back to other stages to block. */
 void block(ThreadID tid);
 
diff -r 1ba825974ee6 -r 6be8945d226b src/cpu/o3/iew_impl.hh
--- a/src/cpu/o3/iew_impl.hhWed Sep 03 07:42:38 2014 -0400
+++ b/src/cpu/o3/iew_impl.hhWed Sep 03 07:42:39 2014 -0400
@@ -530,29 +530,6 @@
 
 templateclass Impl
 void
-DefaultIEWImpl::squashDueToMemBlocked(DynInstPtr inst, ThreadID tid) -{
-DPRINTF(IEW, [tid:%i]: Memory blocked, squashing load and younger insts, 
-PC: %s [sn:%i].\n, tid, inst-pcState(), inst-seqNum);
-if (!toCommit-squash[tid] ||
-inst-seqNum  toCommit-squashedSeqNum[tid]) {
-toCommit-squash[tid] = true;
-
-toCommit-squashedSeqNum[tid] = inst-seqNum;
-toCommit-pc[tid] = inst-pcState();
-toCommit-mispredictInst[tid] = NULL;
-
-// Must include the broadcasted SN in the squash.
-toCommit-includeSquashInst[tid] = true;
-
-ldstQueue.setLoadBlockedHandled(tid);
-
-wroteToTimeBuffer = true;
-}
-}
-
-templateclass Impl
-void
 DefaultIEWImpl::block(ThreadID tid)
 {
 DPRINTF(IEW, [tid:%u]: Blocking.\n, tid); @@ -610,6 +587,20 @@
 
 templateclass Impl
 void
+DefaultIEWImpl::blockMemInst(DynInstPtr inst) {
+instQueue.blockMemInst(inst);
+}
+
+templateclass Impl
+void
+DefaultIEWImpl::cacheUnblocked()
+{
+instQueue.cacheUnblocked();
+}
+
+templateclass Impl
+void
 DefaultIEWImpl::instToCommit(DynInstPtr inst)  {
 // This function should not be called after writebackInsts in a @@ 
-1376,15 +1367,6 @@
 squashDueToMemOrder(violator, tid);
 
 ++memOrderViolationEvents;
-} else if (ldstQueue.loadBlocked(tid) 
-   !ldstQueue.isLoadBlockedHandled(tid)) {
-fetchRedirect[tid] = true;
-
-DPRINTF(IEW, Load operation couldn't execute because the 
-memory system is blocked.  PC: %s [sn:%lli]\n,
-

Re: [gem5-dev] Review Request 2549: ruby: ruby port: do not check for blocked ports

[Beckmann, Brad via gem5-dev]

I looked at this a long time ago and I concluded it would add more complexity 
to the tester than I wanted to add.  Since then, we have built additional 
testers that don't understand retries.  I would strongly prefer we keep it and 
I'm not sure why you want to remove it.  Can we just move this condition to 
QueuedPort? 

In general, my preference is to have fewer retries between the core models and 
Ruby.  We should only be doing retries when we have structural hazards and the 
testers should not be running in an environment where structures are limited.  
The testers are used to stress the logic and work best when we allow big burst 
of requests.

Brad


-Original Message-
From: Nilay Vaish [mailto:ni...@cs.wisc.edu] 
Sent: Tuesday, December 09, 2014 4:56 PM
To: Beckmann, Brad
Cc: Default
Subject: Re: Review Request 2549: ruby: ruby port: do not check for blocked 
ports

On Tue, 9 Dec 2014, Brad Beckmann wrote:


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



 src/mem/ruby/system/RubyPort.cc
 http://reviews.gem5.org/r/2549/#comment5048

Why are you removing these lines?  Is the tester now aware when the
port is blocked and does it handle retries correctly?  I would prefer
if it did not.  We want the tester to be as aggressive as possible.

I am aware that the tester needs to change.  Brad, is there any problem if the 
tester just tries to send packets even when the port is blocked?  At most it 
would fail.

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

Re: [gem5-dev] Protocol Specific Profiling

[Beckmann, Brad via gem5-dev]

Thanks Nilay for the response.

I like the idea of statically defining MachineType and all the associated 
helper functions.  Let's plan on doing that.

Brad



-Original Message-
From: Nilay Vaish [mailto:ni...@cs.wisc.edu] 
Sent: Wednesday, December 03, 2014 11:26 AM
To: Beckmann, Brad
Cc: gem5 Developer List (gem5-dev@gem5.org)
Subject: RE: Protocol Specific Profiling

On Wed, 3 Dec 2014, Beckmann, Brad wrote:

 I have more questions/issues on this topic of protocol specific 
 profiling.  I do not believe this issues should be fixed by having 
 SLICC understand more STL types.  I should have pointed out before 
 that many times it is not one specific protocol that needs special 
 profiling, but rather a set of protocols that need special profiling.  
 In the past, this has been handled by adding special profiling to 
 either the profiler or sequencer, often by using the 
 GenericMachineType.  Unfortunately, you've removed GenericMachineType 
 so if one where to compile a protocol that did not create those 
 specific machine types, any special profiling functions that relied on 
 them will fail to build.  Why did you remove that enum definition from 
 RubySlicc_Types.sm?  Is there any reason we cannot add it back?



I am ok with adding GenericMachineType back.  In addition, I would prefer that 
we stop defining MachineType dynamically and instead make each MachineType used 
in a .sm file be one of those generic types.  I think this will also allow us 
to compile all the protocols simultaneously.

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

Re: [gem5-dev] testing

[Beckmann, Brad via gem5-dev]

Hi Ali,

I'm very interested to learn more about this new memory checker you've 
created.  When do you expect to post your patch or can you explain a bit more 
of what it does?  We've (AMD) have created a pretty significant relaxed memory 
model checker that is compatible with Ruby, but we have a lot of work to do 
before it is ready to shared externally.  I'm curious to know whether you've 
created something similar.

Thanks,

Brad



-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Ali Saidi via 
gem5-dev
Sent: Thursday, December 04, 2014 3:12 AM
To: gem5 Developer List
Subject: Re: [gem5-dev] testing

Hi Gabe/Steve,

As Steve mentioned I¹ve been working on a new take on the regression system in 
my spare-time.

I want to get it a bit more complete before I show it to the world, but some of 
the goals I set out with align with yours.

In particular I¹m targeting the following:
(1) Success/Failure being more that stats or Œgem5 terminated because of ...¹. 
I have a range of criteria that can be specified by test from finding certain 
output on the terminal, in the stdout/stderr files, stats, etc. This code is 
easily extensible so other criteria could be easily added.
(2) Adding a test should be easy. I think we should be testing our config files 
along with gem5 not a custom set of configs, so the regression tester takes 
command lines to gem5 that should be tested.
(3) Tests should be able to be selected on many criteria. Right now we tests 
architectures and fs/se separately but everything else is batched together. 
It¹s annoyingly hard to specify requirements like, ³test o3 cpu on all 
architectures² on ³just run ruby tests.²
(4) Allow simulation on a cluster/cloud if the resources are available to the 
user, but still work on a single machine. This at least provides more 
parallelism in running the regression tests.
(5) Support for dependent tests. The notion that test A must be run and 
generate output before test B can be run is really powerful and lets you create 
tests that generate checkpoints and restore from them or only restore from them 
which would let us get to the interesting parts of tests much more quickly.
(6) Much better reporting of tests, being able to output differences between 
different regression runs, etc.


I view some of the points your brought up as orthogonal to this, although still 
very important.

Much better unit testing would be great, although I think this is a separate 
kind of testing from what we traditionally do for regression tests. I spent a 
long time trying to bend various unit test frameworks into something that we 
could use to run regression tests and they all had issues in doing so. The 
question is how can we sensibly unit test some of these components without 
spending huge amounts of effort mocking up interfaces? Something that we¹ve 
done which has improved the situation a bit is NoISA tests for the memory 
system. This is not a unit-test but more of a directed-test. Isolating the 
memory system and coupling it with a memory checker we¹re about to post should 
give better indication of correctness in the memory system. A good next goal 
here is to hand create some of the tricker cases in the memory system as traces 
we can replay and hopefully verify that they work very quickly instead of 
relying on a few CPUs to hopefully generate that case over millions or billions 
of simulated instructions.

Similarly, we should be able to do much better than the SPEC benchmarks we run 
today for regression tests. You¹re right that ideally we don¹t need to run the 
same loop a million times in a test. Any ideas where we could get something 
that was better?  Preferably something that has self-checking code, freely 
distributable and cover many instructions. I wonder if LLVM or gcc has a 
repository of test code that might be useful?

Finally, I agree that a CI system that could automatically run regressions when 
a patch was posted would be a huge improvement from where we are today.

Thanks,

Ali




On 12/4/14, 7:56 AM, Gabe Black via gem5-dev gem5-dev@gem5.org wrote:

What I'd like is for us not to use stats as a pass/fail criteria. I'm 
not sure how that would work, but using the stats is pretty fragile and 
hard to maintain. It's tricky because you want to make sure the stats 
themselves are still correct, but there are lots of correct stats 
which are different. I agree that automatically deciding how much stats 
should change is not feasible. I haven't had a chance to read that wiki 
page, but one thing I remember, perhaps from the last time this came 
up, is that the regressions we run are benchmarks that do the same 
thing many times to get steady state behavior. To verify something is 
correct, we don't need to loop over the same block of code thousands or 
millions of times. We could probably make things a lot faster without 
losing coverage that way, although changing the regression binaries 
wouldn't 

Re: [gem5-dev] Review Request 2276: ruby: don't make O3 CPU squash on loads that hit outstanding requests

[Beckmann, Brad via gem5-dev]

Nilay,

Coalescing and buffering requests in the Sequencer is very important for good 
performance.  As long as we have a per address interface between our CPU/GPU 
models and Ruby, we need to cache block optimizations in Ruby.

Brad


-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Nilay Vaish via 
gem5-dev
Sent: Thursday, December 04, 2014 7:36 AM
To: Nilay Vaish; Steve Reinhardt; Default
Subject: Re: [gem5-dev] Review Request 2276: ruby: don't make O3 CPU squash on 
loads that hit outstanding requests


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


Steve, is it all right to buffer requests in the Sequencer?  I am not even in 
favor of having a sequencer and buffering requests makes it worse.


src/mem/ruby/system/Sequencer.cc
http://reviews.gem5.org/r/2276/#comment5024

initialize to false?


- Nilay Vaish


On June 21, 2014, 5 p.m., Steve Reinhardt wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.gem5.org/r/2276/
 ---
 
 (Updated June 21, 2014, 5 p.m.)
 
 
 Review request for Default.
 
 
 Repository: gem5
 
 
 Description
 ---
 
 Changeset 10240:b01d667ec431
 ---
 ruby: don't make O3 CPU squash on loads that hit outstanding requests
 
 Mismatch between O3 and Ruby in handling aliased requests: Ruby 
 returns false when it sees aliased request or memory blocked. O3 
 squash and refetch when it sees false signal from Ruby.
 
 Fix: Merging readRequestTable and writeRequestTable in a single table 
 that maps requesting address and all requests that are aliased with 
 the address.
 
 This work was done while Binh was an intern at AMD Research.
 
 
 Diffs
 -
 
   src/mem/packet.cc b21b3aad6bd1d01ac8a4d8030479bbca417af8d1 
   src/mem/protocol/RubySlicc_Exports.sm 
 b21b3aad6bd1d01ac8a4d8030479bbca417af8d1 
   src/mem/ruby/system/DMASequencer.hh 
 b21b3aad6bd1d01ac8a4d8030479bbca417af8d1 
   src/mem/ruby/system/DMASequencer.cc 
 b21b3aad6bd1d01ac8a4d8030479bbca417af8d1 
   src/mem/ruby/system/RubyPort.hh b21b3aad6bd1d01ac8a4d8030479bbca417af8d1 
   src/mem/ruby/system/RubyPort.cc b21b3aad6bd1d01ac8a4d8030479bbca417af8d1 
   src/mem/ruby/system/RubyPortProxy.hh 
 b21b3aad6bd1d01ac8a4d8030479bbca417af8d1 
   src/mem/ruby/system/RubyPortProxy.cc 
 b21b3aad6bd1d01ac8a4d8030479bbca417af8d1 
   src/mem/ruby/system/Sequencer.hh b21b3aad6bd1d01ac8a4d8030479bbca417af8d1 
   src/mem/ruby/system/Sequencer.cc 
 b21b3aad6bd1d01ac8a4d8030479bbca417af8d1
 
 Diff: http://reviews.gem5.org/r/2276/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Steve Reinhardt
 


___
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 2551: ruby: slicc: have a static MachineType

[Beckmann, Brad via gem5-dev]

That is impressive that you got all the gem5-gpu code to stay within EXTRAS!  
Do you do any customized profiling in your protocols, or do you rely on simple 
gem5 statistics?

I agree that it would be great if we could dynamically extend an enumeration 
using EXTRAS.  If we could dynamically modify the RubySlicc_interfaces.slicc 
file using scons EXTRAS, that would be a good start.

Does anyone understand scons well enough to do something like that?

Brad



-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Jason Power via 
gem5-dev
Sent: Thursday, December 04, 2014 11:28 AM
To: gem5 Developer List; Nilay Vaish
Subject: Re: [gem5-dev] Review Request 2551: ruby: slicc: have a static 
MachineType

Hi Nilay, Brad,

I don't love this solution to the MachineType problem. By specifying all of the 
machine types statically in the gem5 source, it makes it so the protocols we 
use in gem5-gpu must modify files in gem5 to work. As it currently is 
implemented, on the Ruby side at least, all of the gem5-gpu code can stay in 
EXTRAS, which I think is a good design.

For instance our protocols have both an L1Cache and a GPUL1Cache which are 
separate machine types. With this patch, we will have to modify 
src/mem/protocol/RubySlicc_Exports.sm to get our protocols to compile.

Maybe there's a way to dynamically extend this enumeration to include other 
machine types defined in the *.sm files of the protocol? Or maybe I am missing 
something in this patch?

Thanks,
Jason

On Thu Dec 04 2014 at 12:17:11 PM Nilay Vaish via gem5-dev  gem5-dev@gem5.org 
wrote:


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

 Review request for Default.


 Repository: gem5


 Description
 ---

 Changeset 10594:b25131489b95
 ---
 ruby: slicc: have a static MachineType This patch moves from a 
 dynamically defined MachineType to a statically defined one.  The need 
 for this patch was felt since a dynamically defined type prevents us 
 from having types for which no machine definition may exist.

 The following changes have been made:
 i. each machine definition now uses a type from the MachineType 
 enumeration instead of any random identifier.  This required changing 
 the grammar and the *.sm files.

 ii. MachineType enumeration defined statically in RubySlicc_Exports.sm.


 Diffs
 -

   src/mem/protocol/MESI_Two_Level-L1cache.sm fea29fc045ee
   src/mem/protocol/MESI_Two_Level-L2cache.sm fea29fc045ee
   src/mem/protocol/MESI_Two_Level-dir.sm fea29fc045ee
   src/mem/protocol/MESI_Two_Level-dma.sm fea29fc045ee
   src/mem/protocol/RubySlicc_Exports.sm fea29fc045ee
   src/mem/slicc/ast/DeclListAST.py fea29fc045ee
   src/mem/slicc/ast/MachineAST.py fea29fc045ee
   src/mem/slicc/parser.py fea29fc045ee
   src/mem/slicc/symbols/SymbolTable.py fea29fc045ee
   src/mem/slicc/symbols/Type.py fea29fc045ee

 Diff: http://reviews.gem5.org/r/2551/diff/


 Testing
 ---


 Thanks,

 Nilay Vaish

 ___
 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] changeset in gem5: ruby: slicc: change the way configurable memb...

[Beckmann, Brad via gem5-dev]

In SLICC we also use commas to separate parameters passed into a function or 
class...like most other languages I'm aware of.  Using semi-colons seems 
awkward.

I understand your point about message buffers, but that is only a problem 
because we are trying to pass these objects as parameters.  Actually the fact 
that we declare and essentially pass the message buffers out of machine rather 
than pass them in is very awkward altogether.  Many years ago we actually had a 
separate file the declared all the virtual channels needed in the protocol.  
Perhaps we should go back to that...maybe even using python to declare virtual 
channels.  That would be a far less confusing notation than what is currently 
supported.

I'm not sure where all this confusing SLICC notation is going and I would 
prefer if we just kept it as is.  I think we all rather be doing interesting 
research rather than conforming our protocol files to some new notation for the 
sake of change.

Brad



-Original Message-
From: Nilay Vaish [mailto:ni...@cs.wisc.edu] 
Sent: Tuesday, December 02, 2014 12:48 PM
To: Beckmann, Brad
Cc: gem5 Developer List
Subject: RE: [gem5-dev] changeset in gem5: ruby: slicc: change the way 
configurable memb...

On Tue, 2 Dec 2014, Beckmann, Brad wrote:

 Hi Nilay,

 Could you explain the motivation behind this change?  What was wrong 
 with the previous notation that data member declarations are separated 
 by commas rather than semi-colons?

I think in most places in SLICC we use comma to separate the attributes of a 
variable.  So, having a different meaning for comma when used while declaring 
parameters does not seem right to me.  Second, message buffers typically have 
several attributes with them.  If we were to retain the comma as separator, 
then it would not be possible to specify message buffers as parameters.

--
Nilay

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

Re: [gem5-dev] changeset in gem5: ruby: slicc: change the way configurable memb...

[Beckmann, Brad via gem5-dev]

Hi Nilay,

Could you explain the motivation behind this change?  What was wrong with the 
previous notation that data member declarations are separated by commas rather 
than semi-colons?

This is the type of seemingly unnecessary change that make it difficult for 
users to stay in sync with the public tree.  Can we please make an effort not 
to do this in the future!

Thanks,

Brad



-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Nilay Vaish via 
gem5-dev
Sent: Monday, September 01, 2014 2:54 PM
To: gem5-...@m5sim.org
Subject: [gem5-dev] changeset in gem5: ruby: slicc: change the way configurable 
memb...

changeset 8c0870dbae5c in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=8c0870dbae5c
description:
ruby: slicc: change the way configurable members are specified
There are two changes this patch makes to the way configurable members 
of a
state machine are specified in SLICC.  The first change is that the data
member declarations will need to be separated by a semi-colon instead 
of a
comma.  Secondly, the default value to be assigned would now use SLICC's
assignment operator i.e. ':='.

diffstat:

 src/mem/protocol/MESI_Three_Level-L0cache.sm|  12 
 src/mem/protocol/MESI_Three_Level-L1cache.sm|  11 +++
 src/mem/protocol/MESI_Two_Level-L1cache.sm  |  20 +++---
 src/mem/protocol/MESI_Two_Level-L2cache.sm  |   8 ++--
 src/mem/protocol/MESI_Two_Level-dir.sm  |   8 ++--
 src/mem/protocol/MESI_Two_Level-dma.sm  |   4 +-
 src/mem/protocol/MI_example-cache.sm|  10 +++---
 src/mem/protocol/MI_example-dir.sm  |   6 ++--
 src/mem/protocol/MI_example-dma.sm  |   4 +-
 src/mem/protocol/MOESI_CMP_directory-L1cache.sm |  14 +-
 src/mem/protocol/MOESI_CMP_directory-L2cache.sm |   6 ++--
 src/mem/protocol/MOESI_CMP_directory-dir.sm |   6 ++--
 src/mem/protocol/MOESI_CMP_directory-dma.sm |   6 ++--
 src/mem/protocol/MOESI_CMP_token-L1cache.sm |  29 ++--
 src/mem/protocol/MOESI_CMP_token-L2cache.sm |  10 +++---
 src/mem/protocol/MOESI_CMP_token-dir.sm |  14 +-
 src/mem/protocol/MOESI_CMP_token-dma.sm |   4 +-
 src/mem/protocol/MOESI_hammer-cache.sm  |  18 ++--
 src/mem/protocol/MOESI_hammer-dir.sm|  12 
 src/mem/protocol/MOESI_hammer-dma.sm|   4 +-
 src/mem/protocol/Network_test-cache.sm  |   4 +-
 src/mem/slicc/ast/FormalParamAST.py |   1 +
 src/mem/slicc/ast/ObjDeclAST.py |   3 +-
 src/mem/slicc/ast/StallAndWaitStatementAST.py   |   2 +-
 src/mem/slicc/parser.py |  30 ++---
 src/mem/slicc/symbols/StateMachine.py   |  35 +++--
 26 files changed, 149 insertions(+), 132 deletions(-)

diffs (truncated from 639 to 300 lines):

diff -r 6df951dcd7d9 -r 8c0870dbae5c 
src/mem/protocol/MESI_Three_Level-L0cache.sm
--- a/src/mem/protocol/MESI_Three_Level-L0cache.sm  Mon Sep 01 16:55:44 
2014 -0500
+++ b/src/mem/protocol/MESI_Three_Level-L0cache.sm  Mon Sep 01 16:55:45 
2014 -0500
@@ -27,12 +27,12 @@
  */
 
 machine(L0Cache, MESI Directory L0 Cache)
- : Sequencer * sequencer,
-   CacheMemory * Icache,
-   CacheMemory * Dcache,
-   Cycles request_latency = 2,
-   Cycles response_latency = 2,
-   bool send_evictions,
+ : Sequencer * sequencer;
+   CacheMemory * Icache;
+   CacheMemory * Dcache;
+   Cycles request_latency := 2;
+   Cycles response_latency := 2;
+   bool send_evictions;
 {
   // NODE L0 CACHE
   // From this node's L0 cache to the network diff -r 6df951dcd7d9 -r 
8c0870dbae5c src/mem/protocol/MESI_Three_Level-L1cache.sm
--- a/src/mem/protocol/MESI_Three_Level-L1cache.sm  Mon Sep 01 16:55:44 
2014 -0500
+++ b/src/mem/protocol/MESI_Three_Level-L1cache.sm  Mon Sep 01 16:55:45 
2014 -0500
@@ -27,11 +27,11 @@
  */
 
 machine(L1Cache, MESI Directory L1 Cache CMP)
- : CacheMemory * cache,
-   int l2_select_num_bits,
-   Cycles l1_request_latency = 2,
-   Cycles l1_response_latency = 2,
-   Cycles to_l2_latency = 1,
+ : CacheMemory * cache;
+   int l2_select_num_bits;
+   Cycles l1_request_latency := 2;
+   Cycles l1_response_latency := 2;
+   Cycles to_l2_latency := 1;
 {
   // From this node's L1 cache TO the network
   // a local L1 - this L2 bank, currently ordered with directory forwarded 
requests @@ -40,7 +40,6 @@
   MessageBuffer responseToL2, network=To, virtual_network=1, 
ordered=false, vnet_type=response;
   MessageBuffer unblockToL2, network=To, virtual_network=2, 
ordered=false, vnet_type=unblock;
 
-
   // To this node's L1 cache FROM the network
   // a L2 bank - this L1
   MessageBuffer requestFromL2, network=From, virtual_network=0, 
ordered=false, vnet_type=request; diff -r 6df951dcd7d9 -r 8c0870dbae5c 
src/mem/protocol/MESI_Two_Level-L1cache.sm
--- 

Re: [gem5-dev] Protocol Specific Profiling

[Beckmann, Brad via gem5-dev]

I have more questions/issues on this topic of protocol specific profiling.  I 
do not believe this issues should be fixed by having SLICC understand more STL 
types.  I should have pointed out before that many times it is not one specific 
protocol that needs special profiling, but rather a set of protocols that need 
special profiling.  In the past, this has been handled by adding special 
profiling to either the profiler or sequencer, often by using the 
GenericMachineType.  Unfortunately, you've removed GenericMachineType so if one 
where to compile a protocol that did not create those specific machine types, 
any special profiling functions that relied on them will fail to build.  Why 
did you remove that enum definition from RubySlicc_Types.sm?  Is there any 
reason we cannot add it back?

Brad



-Original Message-
From: Nilay Vaish [mailto:ni...@cs.wisc.edu] 
Sent: Monday, November 24, 2014 6:50 PM
To: Beckmann, Brad
Cc: gem5 Developer List (gem5-dev@gem5.org)
Subject: RE: Protocol Specific Profiling

On Tue, 25 Nov 2014, Beckmann, Brad wrote:

 Thanks Nilay for the prompt reply.  An example of a protocol specific 
 statistic would be if say in a region coherence protocol [Power et 
 al.], I was profiling the latencies of downgrade request-acks and I 
 wanted to do that for the cross-product of requestor and request type.  
 That is just one example, there are a million different possible 
 statistics one could imagine wanting to collect.  The specific example 
 isn't important, the important part is we need any easy way to add 
 protocol specific statistic processing.  In other words, I want to 
 collect data that doesn't neatly match a current gem5 statistic type 
 and instead requires some sort of C++ customization before being added to a 
 static data type.

I think you are using a map or vector of some type.  I would probably make 
SLICC understand what those types are.  If you don't want to go that way, then 
you will have to do something similar to the earlier setup. 
Prototype a function in one of the .sm files, then define it say in 
RubySlicc_Util.hh and add the corresponding variable in the Profiler class.


 I'm not advocating for the prior solution.  I completely agree going 
 through the RubySlicc_Profile files was not great, but it is better 
 than going through the AbstractController.  At least the 
 RubySlicc_Profile files were only collecting profile features.  The 
 AbstractController is growing into a beast.  Perhaps what I'm looking 
 for is an AbstractProfiler class that we can offload the current 
 profiling work done by the AbstractController.

Going through the abstract controller can be another way.  I am actually not 
worried about the size of the class, unless you think that some function or 
data member is unecessary.  We can define a class with in the 
AbstractController if you are worried about the profiling variables.  If I am 
counting correctly, there are just three of them right now.


 I like the work you've done to collate statistics from independent 
 object instantiations to a common set of data structures.  We need to 
 work on how those data structures are printed out, but your overall 
 approach seems great.  It seems the real problem we have now is that 
 the generated collateStats functions directly cast to the 
 AbstractController, thus all the stat interface functions need to be 
 in the AbstractController.  Instead, we to generate a protocol 
 specific controller profiler that perhaps inherits from a 
 to-be-determined AbstractProfiler class.


The Profiler class still exists.  You can still define a globally visible 
function that calls on the profiler to store some statistic.  This is what use 
to happen before.  The only other way I can think of is to make SLICC 
understand the different data structures we want to work with and use them in 
.sm files.

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

[gem5-dev] Protocol Specific Profiling

[Beckmann, Brad via gem5-dev]

Hi Nilay,

On July 24, 2013 you removed the RubySlice_Profiler.sm, 
RubySlicc_Profiler_interface.cc and RubySlicc_Profiler_interface.hh files.  See 
changeset 9771:57aac1719f86.  By removing those files, you removed the ability 
to provide protocol specific profiling.  Your comment seems to suggest that you 
expect that all profile functions called by the .sm files to use functions 
defined in AbstractController.  Is that correct?  That solution doesn't seem 
very scalable and it will lead to a very large AbstractController definition 
(I'm quite surprised how much that file has grown in the past two years...20+ 
modifications).

Do you see a better way to support protocol specific profiling?  We could add 
back in the RubySlice_Profiler.sm, RubySlicc_Profiler_interface.cc and 
RubySlicc_Profiler_interface.hh files, but I understand the benefit to have the 
functions be defined on a per machine basis.

Thanks,

Brad

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

Re: [gem5-dev] Protocol Specific Profiling

[Beckmann, Brad via gem5-dev]

Thanks Nilay for the prompt reply.  An example of a protocol specific statistic 
would be if say in a region coherence protocol [Power et al.], I was profiling 
the latencies of downgrade request-acks and I wanted to do that for the 
cross-product of requestor and request type.  That is just one example, there 
are a million different possible statistics one could imagine wanting to 
collect.  The specific example isn't important, the important part is we need 
any easy way to add protocol specific statistic processing.  In other words, I 
want to collect data that doesn't neatly match a current gem5 statistic type 
and instead requires some sort of C++ customization before being added to a 
static data type.

I'm not advocating for the prior solution.  I completely agree going through 
the RubySlicc_Profile files was not great, but it is better than going through 
the AbstractController.  At least the RubySlicc_Profile files were only 
collecting profile features.  The AbstractController is growing into a beast.  
Perhaps what I'm looking for is an AbstractProfiler class that we can offload 
the current profiling work done by the AbstractController.  

I like the work you've done to collate statistics from independent object 
instantiations to a common set of data structures.  We need to work on how 
those data structures are printed out, but your overall approach seems great.  
It seems the real problem we have now is that the generated collateStats 
functions directly cast to the AbstractController, thus all the stat interface 
functions need to be in the AbstractController.  Instead, we to generate a 
protocol specific controller profiler that perhaps inherits from a 
to-be-determined AbstractProfiler class.

Does that make sense to you?

Brad



-Original Message-
From: Nilay Vaish [mailto:ni...@cs.wisc.edu] 
Sent: Monday, November 24, 2014 3:22 PM
To: Beckmann, Brad
Cc: gem5 Developer List (gem5-dev@gem5.org)
Subject: Re: Protocol Specific Profiling

On Mon, 24 Nov 2014, Beckmann, Brad wrote:

 Hi Nilay,

 On July 24, 2013 you removed the RubySlice_Profiler.sm, 
 RubySlicc_Profiler_interface.cc and RubySlicc_Profiler_interface.hh 
 files.  See changeset 9771:57aac1719f86.  By removing those files, you 
 removed the ability to provide protocol specific profiling.  Your

I think you need to define what you mean by protocol specific profiling. 
The .sm file just contained some function prototypes.  The actual definitions 
were calling on the RubySystem to get the RubyProfiler, both of which can be 
instantiated only once.

 comment seems to suggest that you expect that all profile functions 
 called by the .sm files to use functions defined in AbstractController.
 Is that correct?  That solution doesn't seem very scalable and it will 
 lead to a very large AbstractController definition (I'm quite 
 surprised how much that file has grown in the past two years...20+ 
 modifications).

If you need a new statistic, it should be defined in the .sm file for the 
controller that needs the statistic.  That would be protocol specific. 
Defining everything in a single place is not protocol specific.


 Do you see a better way to support protocol specific profiling?  We 
 could add back in the RubySlice_Profiler.sm, 
 RubySlicc_Profiler_interface.cc and RubySlicc_Profiler_interface.hh 
 files, but I understand the benefit to have the functions be defined 
 on a per machine basis.


If you want the previous setup back, you can bring it back.  Otherwise you can 
add code to RubySlicc_Util.hh in fashion similar to RubySlicc_Profiler.hh.


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

Re: [gem5-dev] Memory directory structure

[Beckmann, Brad via gem5-dev]

Thanks for clarifying that the classic model already has crossbars and snoop 
filters.  I was not aware of that.

As far as changing paths goes, I'm not claiming the effort to fix a single 
repository is high.  However, there are *a lot* of people within AMD using gem5 
and many customized versions of gem5 exist throughout the company.  I would 
strong prefer not to have to communicate that everyone using gem5 needs to run 
a sed script before updating to the latest repo.  While the script seems 
straightforward to you (Nilay and Andreas) there are many people who don't want 
to deal with these sort of complexities.  In general, we have a lot of current 
users out there.  We should do our best to avoid these sort of changes.

Brad



-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Nilay Vaish via 
gem5-dev
Sent: Wednesday, November 12, 2014 6:01 AM
To: Andreas Hansson via gem5-dev
Subject: Re: [gem5-dev] Memory directory structure

Brad, would not a couple of sed commands be enough for fixing paths in existing 
patches?  I think we should let Andreas move slicc and protocol directory to 
ruby and he would provide a sed script that fixes everything. 
In fact, if we can, we should have things separated out into three
directories: common (port stuff), classic and ruby.  Common code can still 
reside in src/mem as it is currently.

As far as the replicated components are concerned, I don't think it would be 
possible for one memory system to use what the other provides unless somebody 
is willing to make significant changes to at least one of the two systems.  
Note that classic does not understand ruby's messages and flits and ruby only 
partly understands what packets are.  Therefore, Andreas can make an 
interconnect directory but that would contain only classic components for the 
time being.

--
Nilay


On Wed, 12 Nov 2014, Andreas Hansson via gem5-dev wrote:

 Hi Brad,

 I suspected there would be issues lurking. Mostly the benefit would 
 be: 1) clarity for people not familiar with the code base, and 2) work 
 towards building the entire memory system independent of the ISA (and 
 put in a libmem.a or similar). If moving the directories is causing 
 significant problems on your side then we can hold off.

 I am not sure I understand your second point. The Œclassic¹ memory 
 system already has crossbars and snoop filters, I am merely suggesting 
 to not have a big flat src/mem directory, but create some structure. 
 Are you suggesting to put the Œclassic¹ components in src/mem/ruby?

 Andreas

 On 11/12/14, 12:06 AM, Beckmann, Brad via gem5-dev 
 gem5-dev@gem5.org
 wrote:

 I understand that protocol and slicc directories are logically 
 underneath Ruby, but I strongly content the small benefit of moving 
 those directories does not justify the work it will create 
 downstream.  There is a lot of code that works on top of the current 
 directory structure.  I would really appreciate if we didn't make that 
 change.

 Also Ruby already implements crossbars, snoop filters, and other 
 interconnect/coherence structures.  Why not just use those rather 
 than add a new interconnect subdir?

 Brad



 -Original Message-
 From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Nilay 
 Vaish via gem5-dev
 Sent: Tuesday, November 11, 2014 3:37 PM
 To: Andreas Hansson via gem5-dev
 Subject: Re: [gem5-dev] Memory directory structure

 I am fine with the proposed changes.

 --
 Nilay

 On Tue, 11 Nov 2014, Andreas Hansson via gem5-dev wrote:

 Hi all,

 I was contemplating adding a src/mem/ram subdirectory and put the 
 DRAM and SimpleMemory files there.

 I would also like to propose to move src/mem/protocol and 
 src/mem/slicc into the src/mem/ruby subdirectory as they are unique 
 to Ruby. Does that make sense?

 It might be worth creating a src/mem/interconnect subdir as well for 
 the crossbar, bridges, snoop filter etc.

 Thoughts?

 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.

 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

 ___
 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

Re: [gem5-dev] Memory directory structure

[Beckmann, Brad via gem5-dev]

I understand that protocol and slicc directories are logically underneath Ruby, 
but I strongly content the small benefit of moving those directories does not 
justify the work it will create downstream.  There is a lot of code that works 
on top of the current directory structure.  I would really appreciate if we 
didn't make that change.

Also Ruby already implements crossbars, snoop filters, and other 
interconnect/coherence structures.  Why not just use those rather than add a 
new interconnect subdir?

Brad



-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Nilay Vaish via 
gem5-dev
Sent: Tuesday, November 11, 2014 3:37 PM
To: Andreas Hansson via gem5-dev
Subject: Re: [gem5-dev] Memory directory structure

I am fine with the proposed changes.

--
Nilay

On Tue, 11 Nov 2014, Andreas Hansson via gem5-dev wrote:

 Hi all,

 I was contemplating adding a src/mem/ram subdirectory and put the DRAM and 
 SimpleMemory files there.

 I would also like to propose to move src/mem/protocol and src/mem/slicc into 
 the src/mem/ruby subdirectory as they are unique to Ruby. Does that make 
 sense?

 It might be worth creating a src/mem/interconnect subdir as well for the 
 crossbar, bridges, snoop filter etc.

 Thoughts?

 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.

 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

___
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 2466: ruby: provide a second copy of the memory

[Beckmann, Brad via gem5-dev]

I agree with Joel that this has been an interesting discussion.  While there 
are questions about how these situations can occur and what is the best way to 
fix them, there doesn't seem to be anyone resisting the fact that this patch 
should be checked in, correct?  I think it is very important that we not 
require protocols to always provide completely functional memory.  

Brad

-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Steve Reinhardt 
via gem5-dev
Sent: Monday, October 27, 2014 10:02 AM
To: Nilay Vaish
Cc: gem5 Developer List
Subject: Re: [gem5-dev] Review Request 2466: ruby: provide a second copy of the 
memory

On Mon, Oct 27, 2014 at 6:58 AM, Nilay Vaish ni...@cs.wisc.edu wrote:

 On Sun, 26 Oct 2014, Steve Reinhardt wrote:

  On Sun, Oct 26, 2014 at 2:23 PM, Nilay Vaish ni...@cs.wisc.edu wrote:


 Marc Orr asked me the same question last year.  I am pasting the 
 examples I gave him:

 a. the data in the message is stale, but the sender does not know 
 about it. Take a look at the MESI CMP directory protocol. In the 
 case when an
 L1
 controller (A) sends a PUTX to the L2 controller, it is possible 
 that the
 L2 controller has already transferred the ownership to some L1 
 controller (B). In this case, it is possible that there are two 
 message buffers that contain messages from A and B to the L2 
 controller, but it is message from B which has the 'right' data.


 Interesting.  I can see how this technically could be a problem, but 
 it seems like a pretty unlikely corner case. Have you seen it happen 
 in practice, and if so, what was the functional read for?  I suppose 
 I just have a hard time imagining an actual program that has a lot of 
 contention on a block that ends up being used as a parameter to a 
 system call.  I guess it could happen with a syscall that's 
 specifically for synchronization, like futex.


 About an year, I had actually committed a patch that returned the 
 first data value it found (after making sure that no controller had 
 the block in a stable state).  I ran into the case illustrated above 
 and I had to rollback the patch.


Do you recall any details of how you ran into this?  Was this in the process of 
executing an emulated syscall?  How did you detect the problem?


 b. no data is present in the message and the receiver will infer that 
 the
 data it has is correct since the message did not have any data.


 This seems like it should pretty easy to fix... if you're querying 
 the message to see if it has relevant data, then if the address 
 matches but there is no data, you should just return false.  I'd 
 think there'd be a protocol-independent way to determine that a 
 message has no data.  It's similar to the idea that you have to check 
 the valid bit in the cache, you can't just look for a tag match.


 I doubt we can do this in protocol independent way.  I think the 
 presence / absence of data is decided by the type of the message which 
 is a protocol specific enum.


I don't see how this is any harder than having the cache controller know 
whether a block is valid or writable in a protocol-independent fashion.
Unless the entire message format is completely protocol defined, I'd think it 
would be even easier, since you could directly check whether there's a data or 
payload section in the message.

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 2209: ruby: no functional physical memory

[Beckmann, Brad via gem5-dev]

Just to clarify my point to Nilay about no functional physical memory.  We need 
to make this configurable.  There are plenty of protocols that exist, include 
many at AMD, that still rely on a separate copy of functional physical memory.

Thanks,

Brad



-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Andreas Hansson 
via gem5-dev
Sent: Tuesday, October 21, 2014 8:07 AM
To: Nilay Vaish
Cc: Default
Subject: Re: [gem5-dev] Review Request 2209: ruby: no functional physical memory

Hi Nilay,

Thanks for the feedback. I merely wanted to avoid as much rebasing as possible, 
and your patches feed nicely into some of the memory cleanups that are ongoing 
on our side.

Andreas

On 21/10/2014 15:23, Nilay Vaish ni...@cs.wisc.edu wrote:

This is going to take sometime.  Brad and I had a chat two weeks back 
and there is some work that I need to do.  I am currently unsure how 
soon I would it, probably another week or so.

Am I blocking any of your patches?

Thanks
Nilay


On Tue, 21 Oct 2014, Andreas Hansson wrote:


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


 Would be good to get this and the other Ruby/memory system 
interaction patches out there.

 - Andreas Hansson


 On Sept. 25, 2014, 4:41 a.m., Nilay Vaish wrote:

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

 (Updated Sept. 25, 2014, 4:41 a.m.)


 Review request for Default.


 Repository: gem5


 Description
 ---

 Changeset 10417:0763ea34d0f8
 ---
 ruby: no functional physical memory
 This patch removes the functional copy of memory that was in place 
for  ruby fs simulations.  All the memory accesses now source and 
sink values  to the memory maintained by ruby.


 Diffs
 -

   configs/example/fs.py d96740732a61
   configs/example/ruby_mem_test.py d96740732a61
   configs/example/ruby_network_test.py d96740732a61
   configs/example/ruby_random_test.py d96740732a61
   configs/ruby/MESI_Two_Level.py d96740732a61
   configs/ruby/MOESI_CMP_directory.py d96740732a61
   configs/ruby/MOESI_CMP_token.py d96740732a61
   configs/ruby/MOESI_hammer.py d96740732a61
   src/mem/protocol/MESI_Two_Level-dma.sm d96740732a61
   src/mem/protocol/MOESI_CMP_directory-dma.sm d96740732a61
   src/mem/protocol/MOESI_CMP_token-dma.sm d96740732a61
   src/mem/ruby/system/DMASequencer.hh d96740732a61
   src/mem/ruby/system/DMASequencer.cc d96740732a61
   src/mem/ruby/system/RubyPort.hh d96740732a61
   src/mem/ruby/system/RubyPort.cc d96740732a61
   src/mem/ruby/system/Sequencer.py d96740732a61
   tests/configs/pc-simple-timing-ruby.py d96740732a61

 Diff: http://reviews.gem5.org/r/2209/diff/


 Testing
 ---


 Thanks,

 Nilay Vaish







-- 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
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 2112: stats: updates to changes to ruby

[Beckmann, Brad]

Nilay,

Can you please wait a few more days?  I likely won't have a chance to look at 
this until next week.

Brad


-Original Message-
From: gem5-dev-boun...@gem5.org [mailto:gem5-dev-boun...@gem5.org] On Behalf Of 
Nilay Vaish
Sent: Thursday, December 19, 2013 6:16 PM
To: gem5 Developer List (gem5-dev@gem5.org)
Subject: Re: [gem5-dev] Review Request 2112: stats: updates to changes to ruby

Are there any other comments / questions / suggestions about the patch on doing 
away with ruby.stats?

--
Nilay


On Tue, 17 Dec 2013, Nilay Vaish wrote:

 Brad, take a look at
 tests/quick/se/50.memtest/ref/alpha/linux/memtest-ruby-MESI_CMP_directory/stats.txt.

 --
 Nilay


 On Mon, 16 Dec 2013, Beckmann, Brad wrote:

 Hi Nilay,
 
 Unless you've modified the stats infrastructure to print out counts 
 on the same line, when you run with two CPU cores, you will see 
 separate lines in stats.txt for the stats of L1 cache controller 0 and L1 
 cache controller 1.
 In ruby.stats, these counts will appear as a list on the same line.
 
 For example see the system.ruby.l1_cntrl0.I.Load line in file: 
 tests/quick/se/00.hello/ref/alpha/linux/simple-timing-ruby-MESI_CMP_d
 irectory/stats.txt
 
 Brad
 
 
 
 -Original Message-
 From: Nilay Vaish [mailto:ni...@cs.wisc.edu]
 Sent: Monday, December 16, 2013 11:53 AM
 To: Beckmann, Brad
 Cc: Default
 Subject: RE: Review Request 2112: stats: updates to changes to ruby
 
 On Thu, 12 Dec 2013, Beckmann, Brad wrote:
 
 An example of concise stats is the current format of the generated 
 slicc stats in the ruby.stats file.  My primary concern is with the 
 generated state transition stats when many controllers of the same 
 type exist.
 With the ruby.stats format, all the individual controller counts 
 would be on the same line.  With the stats.txt format, those counts 
 are spread across 16 separate lines throughout the file. I don't how 
 anyone could consider that format concise.
 
 Which controller count are you talking about?  If originally 
 ruby.stats had the counts on the same line, unless I made a mistake 
 somewhere, I would have written code so as to print those counts on the same 
 line.
 
 
 I don't think I'm asking for a lot here.  I just want the generated 
 state transition stats to maintain a similar format.  The stats.txt 
 file already supports a condensed histogram format.  Can we do the 
 same for the controller stats?
 
 
 
 
 
 --
 Nilay
 
 
 
 

___
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 2112: stats: updates to changes to ruby

[Beckmann, Brad]

Hi Nilay,

Unless you've modified the stats infrastructure to print out counts on the same 
line, when you run with two CPU cores, you will see separate lines in stats.txt 
for the stats of L1 cache controller 0 and L1 cache controller 1.  In 
ruby.stats, these counts will appear as a list on the same line.

For example see the system.ruby.l1_cntrl0.I.Load line in file: 
tests/quick/se/00.hello/ref/alpha/linux/simple-timing-ruby-MESI_CMP_directory/stats.txt

Brad



-Original Message-
From: Nilay Vaish [mailto:ni...@cs.wisc.edu] 
Sent: Monday, December 16, 2013 11:53 AM
To: Beckmann, Brad
Cc: Default
Subject: RE: Review Request 2112: stats: updates to changes to ruby

On Thu, 12 Dec 2013, Beckmann, Brad wrote:

 An example of concise stats is the current format of the generated 
 slicc stats in the ruby.stats file.  My primary concern is with the 
 generated state transition stats when many controllers of the same type exist.
 With the ruby.stats format, all the individual controller counts would 
 be on the same line.  With the stats.txt format, those counts are 
 spread across 16 separate lines throughout the file. I don't how 
 anyone could consider that format concise.

Which controller count are you talking about?  If originally ruby.stats had the 
counts on the same line, unless I made a mistake somewhere, I would have 
written code so as to print those counts on the same line.


 I don't think I'm asking for a lot here.  I just want the generated 
 state transition stats to maintain a similar format.  The stats.txt file 
 already supports a condensed histogram format.  Can we do the same for 
 the controller stats?





--
Nilay


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

Re: [gem5-dev] Review Request 2112: stats: updates to changes to ruby

[Beckmann, Brad]

An example of concise stats is the current format of the generated slicc stats 
in the ruby.stats file.  My primary concern is with the generated state 
transition stats when many controllers of the same type exist.  With the 
ruby.stats format, all the individual controller counts would be on the same 
line.  With the stats.txt format, those counts are spread across 16 separate 
lines throughout the file. I don't how anyone could consider that format 
concise.

I don't think I'm asking for a lot here.  I just want the generated state 
transition stats to maintain a similar format.  The stats.txt file already 
supports a condensed histogram format.  Can we do the same for the controller 
stats?

Brad


-Original Message-
From: Nilay Vaish [mailto:ni...@cs.wisc.edu] 
Sent: Monday, December 09, 2013 12:07 PM
To: Beckmann, Brad
Cc: Default
Subject: Re: Review Request 2112: stats: updates to changes to ruby

On Sat, 7 Dec 2013, Brad Beckmann wrote:


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


 The extreme verbosity of the ruby output concerns me greatly.  While 
 the stats.txt file format is very easy to parse, it is extremely 
 difficult to read.  The generated statistics from ruby controllers are 
 immensely valuable for debugging performance problems and they are 
 read often by humans.  I do not want to delete the ruby.stats file 
 until the stats.txt file can provide ruby generated statistics in a similar 
 concise format.
 I strongly argue against this patch begin checked in until we can fix 
 the stats.txt format.

 Sorry to be so negative on this patch, but I feel pretty strongly about this.


I am open to changes.  It would be good if you can provide examples.  In my 
opinion, readability not only a function of what you are reading but also a 
function of what you are habitual of reading.  With time, the current format 
will also start appearing to be concise.

--
Nilay


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

Re: [gem5-dev] Review Request 2111: ruby: move all statistics to stats.txt, eliminate ruby.stats

[Beckmann, Brad]

Hi Nilay,

Can you send out a sample stats.txt file for a Ruby that includes this patch?

Thanks,

Brad

-Original Message-
From: gem5-dev-boun...@gem5.org [mailto:gem5-dev-boun...@gem5.org] On Behalf Of 
Nilay Vaish
Sent: Thursday, December 05, 2013 2:22 PM
To: Nilay Vaish; Default
Subject: [gem5-dev] Review Request 2111: ruby: move all statistics to 
stats.txt, eliminate ruby.stats


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

Review request for Default.


Repository: gem5


Description
---

Changeset 9995:725dacb3d68b
---
ruby: move all statistics to stats.txt, eliminate ruby.stats


Diffs
-

  configs/ruby/Ruby.py bdd606534bdc 
  src/mem/ruby/buffers/MessageBuffer.hh bdd606534bdc 
  src/mem/ruby/buffers/MessageBuffer.cc bdd606534bdc 
  src/mem/ruby/profiler/AddressProfiler.hh bdd606534bdc 
  src/mem/ruby/profiler/Profiler.hh bdd606534bdc 
  src/mem/ruby/profiler/Profiler.cc bdd606534bdc 
  src/mem/ruby/profiler/Profiler.py bdd606534bdc 
  src/mem/ruby/profiler/SConscript bdd606534bdc 
  src/mem/ruby/slicc_interface/AbstractController.hh bdd606534bdc 
  src/mem/ruby/slicc_interface/AbstractController.cc bdd606534bdc 
  src/mem/ruby/system/RubyPort.hh bdd606534bdc 
  src/mem/ruby/system/RubySystem.py bdd606534bdc 
  src/mem/ruby/system/Sequencer.hh bdd606534bdc 
  src/mem/ruby/system/Sequencer.cc bdd606534bdc 
  src/mem/ruby/system/System.hh bdd606534bdc 
  src/mem/ruby/system/System.cc bdd606534bdc 
  src/mem/ruby/system/WireBuffer.hh bdd606534bdc 
  src/mem/ruby/system/WireBuffer.cc bdd606534bdc 
  src/mem/slicc/symbols/StateMachine.py bdd606534bdc 

Diff: http://reviews.gem5.org/r/2111/diff/


Testing
---


Thanks,

Nilay Vaish

___
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: PacketQueue: Add maxQueueDepth parameter and setter

[Beckmann, Brad]

Thanks Andreas for the responses.  I think we will eventually determine the 
best solution here if we keep this thread up.  Let's keep the information 
flowing.

So your response brings up several thoughts on my end:

- SimpleTimingPort may be a packet queue today, but back when the RubyPort was 
created (see 6882) SimpleTimingPort looked more like a raw point-to-point 
port with no internal, invisible, multi-packet buffering.  I think that is 
where we want to get back to but we need to figure out either how to handle 
deferred response packets or eliminate the possibility for cores to reject 
response packets.  I would prefer the latter solution, but I'm hoping you or 
someone else can help explain why cores currently reject response packets.  Or 
at least there is an expectation that responses may be delayed.

- RubyPort's master request port and it's slaver response port are not 
symmetric.  It is only RubyPort's slave response port that use the packet 
queues.  RubyPort's master port is a raw port that does return false under 
certain situations, including resource stalls.

- The RubyPort is used in realistic finite buffering scenarios, as well as 
scenarios that are unrealistic and that must use infinite buffering.  The 
unrealistic, infinite buffering scenarios are needed for a couple reasons: 1) 
When a protocol is first developed, it is often helpful to first focus on 
getting the logic working correctly.  Then when the initial logic is flushed 
out, performance tuning using finite buffering is done.  2) More importantly, 
we use testers that stress our protocols far beyond what can be achieved by 
realistic scenarios.  In particular, we allow for infinite buffering so that 
requests latencies can be extended and bandwidth bursts can be extreme.  This 
allows us to find protocol logic bugs early and makes supporting multiple 
protocols under a single infrastructure practical.  Writing protocol logic is 
very difficult and these aggressive, unrealistic testers are essential.

- The RubyPort is just an interface and it doesn't represent anything in 
hardware.  Ruby's current assumption with hitcallbacks is that the requestor 
will not stall a response.  The idea is that the requestor should have 
allocated resources ahead of time, before issuing the request to the memory 
system.

- Yes, multiple hitcallbacks occurring at the same time cause the packet queue 
within the RubyPort slave port to panic.  Unfortunately it is not easy for me 
to provide you a simple way to reproduce the error.  However, I don't know if 
it is that important for you to reproduce the error.  Instead, I think we need 
to focus on how we resolve the bigger design inconsistencies in the RubyPort - 
M5 port interface.

Going forward I see a few options:

- Simply remove the panic message in packet queue.  That is essential the quick 
fix we've done at AMD and I suspect that is what the Wisconsin folks have 
effectively done as well.
- Remove any possibility of cores to stall/reject response packets and keep the 
same hitcallback behavior as today.
- Modify hitcallback to support stalled responses.  This will certainly take a 
lot of work, I think we need to better understand the assumptions that the 
cores have regarding retries of the same versus different packets.

Thoughts?  I hope that made sense to you.  Let me know if anything was unclear.

Thanks,

Brad


-Original Message-
From: gem5-dev-boun...@gem5.org [mailto:gem5-dev-boun...@gem5.org] On Behalf Of 
Andreas Hansson
Sent: Wednesday, October 09, 2013 12:43 AM
To: gem5 Developer List; Jason Power; Joel Hestness
Subject: Re: [gem5-dev] Review Request: PacketQueue: Add maxQueueDepth 
parameter and setter

Hi Brad,

The SimpleTimingPort is a packet queue, so the functionality would have been 
the same (just with an infinite buffer). Hence, there is no point in reverting 
any code. Instead we have to decide what is sensible to model and then change 
it to reflect that.

What is the RubyPort actually modelling? Is is a network interface? If so, if 
the master (CPU/GPU/device/etc) stalls the response, is there any chance of 
propagating that stall? If the answer is no, then can we stall new requests for 
coming from the master port instead (so that we know the max number of 
responses, probably below 100 :-))? If the answer to both is no, then we need 
an infinite queue in the RubyPort, which does feel rather unfortunate (and 
unrealistic).

Is it hitCallback in RubyPort that is causing the issue? Is there any easy way 
for me to reproduce it?

Thanks,

Andreas


On 09/10/2013 01:06, Beckmann, Brad brad.beckm...@amd.com wrote:

Yes, Andreas the Ruby interface uses the PacketQueue for the response 
packets after your changesets 8742 and 8914 (note the modifications to 
RubyPort.hh).  Before you checked in these changes, the RubyPort used a 
simple timing port for response packets.  I believe you checked in 
these changes so that retries would be avoided.

So what

Re: [gem5-dev] Review Request: PacketQueue: Add maxQueueDepth parameter and setter

[Beckmann, Brad]

Yes, Andreas the Ruby interface uses the PacketQueue for the response packets 
after your changesets 8742 and 8914 (note the modifications to RubyPort.hh).  
Before you checked in these changes, the RubyPort used a simple timing port for 
response packets.  I believe you checked in these changes so that retries would 
be avoided.

So what would it take to revert these changes and use a simple slave port for 
responses?  It appears the code modifications are fairly straightforward, but 
I'm worried that the CPU models are not prepared to always sink responses.  I 
guess the begs the second question of why would a CPU or GPU model not always 
sink a response packet?

Brad



-Original Message-
From: gem5-dev-boun...@gem5.org [mailto:gem5-dev-boun...@gem5.org] On Behalf Of 
Andreas Hansson
Sent: Tuesday, October 08, 2013 10:13 AM
To: gem5 Developer List; Jason Power; Joel Hestness
Subject: Re: [gem5-dev] Review Request: PacketQueue: Add maxQueueDepth 
parameter and setter

Hi Brad,

I am actually inclined to say that the packet queue should only be used in 
simple devices to model pipeline latency, and that the value 100 is already too 
large. The only times I've hit this limit is when something in the model is 
broken and not reacting properly. Recently, we switched the simple 
fixed-latency memory model (SimpleMemory) to not use a queued port for this 
very reason. Instead of magically storing lots of transactions it now slows 
things down through back pressure of requests.

I suppose the issue you are seeing is in the cache? I am tempted to say we 
should do something similar as what we did with SimpleMemory with the cache and 
avoid using the queued ports. If that sounds reasonable to you I will try and 
find some time to get this done.

If I'm misunderstanding the use-case causing the problem, I'd be keen to know 
more.

Andreas


On 08/10/2013 01:12, Beckmann, Brad brad.beckm...@amd.com wrote:

Hi Andreas,

I know it has been several months since this topic was brought up, but 
I think it is worth trying to come up with a solution here.  I also 
believe this relates to the gem5-users thread PacketQueue sanity check 
on its invisible buffer size started by Lichen Yu back in May.

Can you clarify why you are pushing back on making this size 
configurable?  The size 100 seems pretty arbitrary and is far too small 
if you consider massively threaded requestors, such as GPUs.  Also it 
doesn't make sense to make these queued ports both finite in size, yet 
their size is invisible to the requestors.

Ideally from the Ruby perspective, I would prefer us to simply remove 
the panic message from packet_queue.cc.  There are other mechanisms in 
place to model finite buffering and the PacketQueue does not represent 
the type of hardware buffering we are envisioning.

Does that work for you?

Brad




-Original Message-
From: gem5-dev-boun...@gem5.org [mailto:gem5-dev-boun...@gem5.org] On 
Behalf Of Andreas Hansson
Sent: Monday, March 18, 2013 12:32 AM
To: Jason Power; Andreas Hansson; Default; Joel Hestness
Subject: Re: [gem5-dev] Review Request: PacketQueue: Add maxQueueDepth 
parameter and setter



 On March 17, 2013, 7:43 p.m., Jason Power wrote:
  Ship It!

Sorry to cause problems here guys, but I think we need to fix this 
another way. The queued port is not supposed to be a free storage 
resource. If it runs out, we should rather block the cache.

Overall, I have been thinking about how we can turn the queued port 
into something that can signal back that it is blocking. It gets a bit 
tricky as you soon end up removing all the functionality of the queued 
port and end up with the send/retry style interface.

In short: I don't think we should ship this, and I'm keen to hear what 
people think is a reasonable way to make the queued port block it's 
MemObject (and start it again without polling).


- Andreas


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


On March 17, 2013, 6:05 p.m., Joel Hestness wrote:

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

 (Updated March 17, 2013, 6:05 p.m.)


 Review request for Default.


 Description
 ---

 Changeset 9587:b989f6228833
 ---
 PacketQueue: Add maxQueueDepth parameter and setter

 The default maximum PacketQueue depth of 100 can cause assertion 
failures when  using the PacketQueue in a setting when the maximum 
queue depth may be known to  be greater than 100 (e.g. modeling 
queuing of outstanding requests to the cache  from aggressive GPU core 
implementations). Parameterize this max depth and add  a method to set 
the max depth.


 Diffs
 -

   src/mem/packet_queue.hh

Re: [gem5-dev] Review Request: PacketQueue: Add maxQueueDepth parameter and setter

[Beckmann, Brad]

Hi Andreas,

I know it has been several months since this topic was brought up, but I think 
it is worth trying to come up with a solution here.  I also believe this 
relates to the gem5-users thread PacketQueue sanity check on its invisible 
buffer size started by Lichen Yu back in May.

Can you clarify why you are pushing back on making this size configurable?  The 
size 100 seems pretty arbitrary and is far too small if you consider massively 
threaded requestors, such as GPUs.  Also it doesn't make sense to make these 
queued ports both finite in size, yet their size is invisible to the requestors.

Ideally from the Ruby perspective, I would prefer us to simply remove the panic 
message from packet_queue.cc.  There are other mechanisms in place to model 
finite buffering and the PacketQueue does not represent the type of hardware 
buffering we are envisioning.

Does that work for you?

Brad




-Original Message-
From: gem5-dev-boun...@gem5.org [mailto:gem5-dev-boun...@gem5.org] On Behalf Of 
Andreas Hansson
Sent: Monday, March 18, 2013 12:32 AM
To: Jason Power; Andreas Hansson; Default; Joel Hestness
Subject: Re: [gem5-dev] Review Request: PacketQueue: Add maxQueueDepth 
parameter and setter



 On March 17, 2013, 7:43 p.m., Jason Power wrote:
  Ship It!

Sorry to cause problems here guys, but I think we need to fix this another way. 
The queued port is not supposed to be a free storage resource. If it runs 
out, we should rather block the cache.

Overall, I have been thinking about how we can turn the queued port into 
something that can signal back that it is blocking. It gets a bit tricky as you 
soon end up removing all the functionality of the queued port and end up with 
the send/retry style interface.

In short: I don't think we should ship this, and I'm keen to hear what people 
think is a reasonable way to make the queued port block it's MemObject (and 
start it again without polling).


- Andreas


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


On March 17, 2013, 6:05 p.m., Joel Hestness wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.gem5.org/r/1777/
 ---
 
 (Updated March 17, 2013, 6:05 p.m.)
 
 
 Review request for Default.
 
 
 Description
 ---
 
 Changeset 9587:b989f6228833
 ---
 PacketQueue: Add maxQueueDepth parameter and setter
 
 The default maximum PacketQueue depth of 100 can cause assertion failures when
 using the PacketQueue in a setting when the maximum queue depth may be known 
 to
 be greater than 100 (e.g. modeling queuing of outstanding requests to the 
 cache
 from aggressive GPU core implementations). Parameterize this max depth and add
 a method to set the max depth.
 
 
 Diffs
 -
 
   src/mem/packet_queue.hh 3c62e3b7f658 
   src/mem/packet_queue.cc 3c62e3b7f658 
 
 Diff: http://reviews.gem5.org/r/1777/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Joel 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] Printing vector statistics

[Beckmann, Brad]

Thanks for doing this.  This has long been a sore spot and it is great that you 
are cleaning this up.  I know that code is not easy to understand.

I like the last option, though the memBuffer statistics are not that important 
to me.

What I care about is the generated controller statistics.  That is where I 
believe it is important to maintain a condensed format.  I assume you're plan 
is to tackle those eventually???

Brad


-Original Message-
From: Nilay Vaish [mailto:ni...@cs.wisc.edu] 
Sent: Wednesday, May 22, 2013 2:09 PM
To: Beckmann, Brad
Cc: gem5-dev@gem5.org
Subject: Printing vector statistics

Hi Brad

I am working on moving more of the statistics collected by ruby to gem5' 
style. To keep the printing similar to that of ruby, I am considering adding an 
option to print vector statistics in gem5 in style different from the current 
one. How would like to see the statistics? I can think of the following three 
options:

1. Keep the style as is. This means all the data values for index in the vector 
are printed on separate lines. For example:

system.ruby.dir_cntrl0.memBuffer.memBankCount::0   19  5.22% 5.22% 
# Number of accesses per bank
system.ruby.dir_cntrl0.memBuffer.memBankCount::1   15  4.12% 9.34% 
# Number of accesses per bank
system.ruby.dir_cntrl0.memBuffer.memBankCount::2   15  4.12% 13.46% 
# Number of accesses per bank
system.ruby.dir_cntrl0.memBuffer.memBankCount::3   19  5.22% 18.68% 
# Number of accesses per bank
system.ruby.dir_cntrl0.memBuffer.memBankCount::4   20  5.49% 24.18% 
# Number of accesses per bank


The first column is the name of stat and the index in the vector, the second 
column is value at the index, the third column is pdf and last one is pdf.

2. Print the data values, the pdf and the cdf on three separate lines. Example:

system.ruby.dir_cntrl0.memBuffer.memBankCount::data 19   15  15  19 
20
system.ruby.dir_cntrl0.memBuffer.memBankCount::pdf  19%  15% 15% 19% 
20%
system.ruby.dir_cntrl0.memBuffer.memBankCount::cdf  19%  34% 49% 68% 
88%

3. Print the data values, the pdf and the cdf together on a single line. 
Example:

system.ruby.dir_cntrl0.memBuffer.memBankCount::[data, pdf, cdf] [19 5.22% 
5.22%] [15 4.12% 9.34%] [15 4.12% 13.46%] [19 5.22% 18.68%] [20 5.49% 24.18%]


--
Nilay


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

Re: [gem5-dev] ruby: collecting cache controller statistics

[Beckmann, Brad]

Hi Nilay,

Sorry I haven't been able to participate in a lot of the public gem5 discussion 
lately, but this is one item that I want to make time for.  We need to be 
careful when making this change.  My primary concerns are that we need to 
maintain that the ruby generated statistics are easily readable and condense.  
Unlike simple stats that are primarily parsed by scripts and used for graphs, 
ruby generated statistics are most useful for debugging performance problems in 
the protocol.  Therefore it is important to make sure we can get a global idea 
of how the protocol is behaving without having to scroll through hundreds or 
thousands of lines.  Ideally I would like to see us maintain the same format as 
they are today with the per-controller counts and the summation all on the same 
line.

Brad


-Original Message-
From: gem5-dev-boun...@gem5.org [mailto:gem5-dev-boun...@gem5.org] On Behalf Of 
Nilay Vaish
Sent: Tuesday, April 23, 2013 12:01 PM
To: gem5-dev@gem5.org
Subject: [gem5-dev] ruby: collecting cache controller statistics

Hi

I am thinking of allowing for using gem5's statistical variables within 
coherence protocol definition files. I think this would help in getting a 
better hold on how statistics are collected from the cache controllers in 
coherence protocols. The current method of calling a function in to the cache 
memory class is largely opaque and not well maintained. Since we would like to 
move away from ruby's way of collecting statistics (at some point in time), it 
seems to me this would be a better way than just replacing 'int' variables with 
'Counter' or 'Scalar' variables in ruby's profiler class. Also, it seems that 
this would allow easier addition of custom statistics that one might want to 
have.

Does any one has opinion on this issue?


Thanks
Nilay
___
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: remove the functional copy of memory in...

[Beckmann, Brad]

This is a research simulator.  I don't understand why we would remove 
functionally that allows us to perform high-level boundary experiments. For 
example, we currently leverage the backing store to determine the performance 
of a system if a certain subset of acceses take X cycles. Maintaining that 
feature is important to me.

We have a ton of code that we currently apply on top of the public tree. 
Maintaining them is a pain whenever there is a substantial system-wide change 
in the underlying infrastructure.  The real problem is the amount of code we 
have, not your specific change to the clocks.

So how big us your bug fix?  How bad is the bug? I don't mind you checking in 
your fix as long as it doesn't touch a lot of Ruby files or change the general 
APIs for a minor bug.

Brad

Sent from my Windows Phone

From: Nilaymailto:ni...@cs.wisc.edu
Sent: ‎3/‎8/‎2013 1:16
To: Beckmann, Bradmailto:brad.beckm...@amd.com
Cc: gem5 Developer Listmailto:gem5-dev@gem5.org
Subject: Re: [gem5-dev] changeset in gem5: ruby: remove the functional copy of 
memory in...

On Wed, March 6, 2013 11:05 pm, Beckmann, Brad wrote:
 Thanks Nilay for checking this in.  I know this is a small patch, but
 there was a lot of previous effort on your part to make it happen.

Would not have been possible with out your help.


 Going forward, I do think it is important to make the backing store
 optional and not remove it completely.  I'm fine if we maintain the
 default as off, but there are a few times when it is nice to leverage the
 backing store for simple boundary experiments.  So if we want to enable
 the backing store for se mode, is it as simple as setting access_phys_mem
 to true and setting the system.physmem.null to true?  Can we modify the
 se.py/Ruby.py to do this using just one command line parameter?

While we can add an option for keeping the functional copy of the memory,
I am not keen on it. I am of the view that once we support pio accesses in
ruby, we should remove the functional memory completely.


 Nilay, I'm still in the midst of a significant rebase of our tree due to
 your clock/time changes.  Please hold off on checking any more Ruby
 changes until I can get our patches out the door.


I was hoping these patches would not interfere with yours. Are you facing
any issues in merging your patches with the clock/time changes? I think I
made some errors in those patches. They manifest while trying to create a
checkpoint or restore from one. I have some changes that correct should do
away with some of the errors.

--
Nilay


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

Re: [gem5-dev] Ruby: multiple copies of physical memory

[Beckmann, Brad]

Do you mean the physmem attached to the ruby ports and the memvec in 
DirectoryMemory?  I hope with your recent functional access update to the 
network messages, we can finally get rid of the former, though I'm not sure how 
we would handle pio acceses.

If you start down that path, let us know.  Derek recently asked about the same 
thing.

Brad

Sent from my Windows Phone

From: Nilaymailto:ni...@cs.wisc.edu
Sent: ‎2/‎22/‎2013 12:06 PM
To: Beckmann, Bradmailto:brad.beckm...@amd.com
Cc: gem5-dev@gem5.orgmailto:gem5-dev@gem5.org
Subject: Ruby: multiple copies of physical memory

Hi Brad

Can you remind me why we need two copies of memory when we are running
with Ruby? Do you have some view on what needs to be done to remove one of
the copies?

--
Nilay


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

Re: [gem5-dev] changeset in gem5: regressions: update stats due to changes to ruby

[Beckmann, Brad]

Hi Nilay,

Do you know why the stat values changed?  The values seem relatively close, but 
I would have expected no changes in the values.

Brad


-Original Message-
From: gem5-dev-boun...@gem5.org [mailto:gem5-dev-boun...@gem5.org] On Behalf Of 
Nilay Vaish
Sent: Monday, February 11, 2013 4:21 PM
To: gem5-...@m5sim.org
Subject: [gem5-dev] changeset in gem5: regressions: update stats due to changes 
to ruby

changeset 921d858c5bc7 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=921d858c5bc7
description:
regressions: update stats due to changes to ruby

diffstat:

 
tests/long/fs/10.linux-boot/ref/x86/linux/pc-simple-timing-ruby-MESI_CMP_directory/config.ini
 |18 +-
 
tests/long/fs/10.linux-boot/ref/x86/linux/pc-simple-timing-ruby-MESI_CMP_directory/ruby.stats
 |   364 +-
 
tests/quick/se/00.hello/ref/alpha/linux/simple-timing-ruby-MESI_CMP_directory/ruby.stats
  |27 +-
 
tests/quick/se/00.hello/ref/alpha/linux/simple-timing-ruby-MOESI_CMP_directory/ruby.stats
 |89 +-
 
tests/quick/se/00.hello/ref/alpha/linux/simple-timing-ruby-MOESI_CMP_token/ruby.stats
 |19 +-
 
tests/quick/se/00.hello/ref/alpha/linux/simple-timing-ruby-MOESI_hammer/ruby.stats
|21 +-
 tests/quick/se/00.hello/ref/alpha/linux/simple-timing-ruby/ruby.stats  
   |27 +-
 
tests/quick/se/00.hello/ref/alpha/tru64/simple-timing-ruby-MESI_CMP_directory/ruby.stats
  |19 +-
 
tests/quick/se/00.hello/ref/alpha/tru64/simple-timing-ruby-MOESI_CMP_directory/ruby.stats
 |81 +-
 
tests/quick/se/00.hello/ref/alpha/tru64/simple-timing-ruby-MOESI_CMP_token/ruby.stats
 |21 +-
 
tests/quick/se/00.hello/ref/alpha/tru64/simple-timing-ruby-MOESI_hammer/ruby.stats
|29 +-
 tests/quick/se/00.hello/ref/alpha/tru64/simple-timing-ruby/ruby.stats  
   |25 +-
 tests/quick/se/00.hello/ref/arm/linux/o3-timing-checker/config.ini 
   |16 +-
 tests/quick/se/00.hello/ref/arm/linux/o3-timing/config.ini 
   |16 +-
 tests/quick/se/00.hello/ref/sparc/linux/inorder-timing/config.ini  
   |16 +-
 tests/quick/se/00.hello/ref/sparc/linux/simple-timing-ruby/ruby.stats  
   |21 +-
 tests/quick/se/02.insttest/ref/sparc/linux/o3-timing/config.ini
   |16 +-
 
tests/quick/se/40.m5threads-test-atomic/ref/sparc/linux/o3-timing-mp/config.ini 
  |16 +-
 
tests/quick/se/50.memtest/ref/alpha/linux/memtest-ruby-MESI_CMP_directory/ruby.stats
  |33 +-
 
tests/quick/se/50.memtest/ref/alpha/linux/memtest-ruby-MOESI_CMP_directory/config.ini
 | 8 +
 
tests/quick/se/50.memtest/ref/alpha/linux/memtest-ruby-MOESI_CMP_directory/ruby.stats
 |  1055 -
 
tests/quick/se/50.memtest/ref/alpha/linux/memtest-ruby-MOESI_CMP_directory/stats.txt
  |44 +-
 
tests/quick/se/50.memtest/ref/alpha/linux/memtest-ruby-MOESI_CMP_token/ruby.stats
 |31 +-
 tests/quick/se/50.memtest/ref/alpha/linux/memtest-ruby-MOESI_hammer/ruby.stats 
   |33 +-
 tests/quick/se/50.memtest/ref/alpha/linux/memtest-ruby/ruby.stats  
   |33 +-
 
tests/quick/se/60.rubytest/ref/alpha/linux/rubytest-ruby-MESI_CMP_directory/ruby.stats
|17 +-
 
tests/quick/se/60.rubytest/ref/alpha/linux/rubytest-ruby-MOESI_CMP_directory/ruby.stats
   |   353 +-
 
tests/quick/se/60.rubytest/ref/alpha/linux/rubytest-ruby-MOESI_CMP_directory/stats.txt
|12 +-
 
tests/quick/se/60.rubytest/ref/alpha/linux/rubytest-ruby-MOESI_CMP_token/ruby.stats
   |11 +-
 
tests/quick/se/60.rubytest/ref/alpha/linux/rubytest-ruby-MOESI_hammer/ruby.stats
  |21 +-
 tests/quick/se/60.rubytest/ref/alpha/linux/rubytest-ruby/ruby.stats
   |21 +-
 31 files changed, 1256 insertions(+), 1257 deletions(-)

diffs (truncated from 4644 to 300 lines):

diff -r 0adea7868e77 -r 921d858c5bc7 
tests/long/fs/10.linux-boot/ref/x86/linux/pc-simple-timing-ruby-MESI_CMP_directory/config.ini
--- 
a/tests/long/fs/10.linux-boot/ref/x86/linux/pc-simple-timing-ruby-MESI_CMP_directory/config.ini
 Sun Feb 10 21:43:18 2013 -0600
+++ 
b/tests/long/fs/10.linux-boot/ref/x86/linux/pc-simple-timing-ruby-MESI_CMP_directory/config.ini
 Sun Feb 10 21:43:23 2013 -0600
@@ -54,6 +54,7 @@
 [system.cpu0]
 type=TimingSimpleCPU
 children=dtb interrupts isa itb tracer
+branchPred=Null
 checker=Null
 clock=500
 cpu_id=0
@@ -124,6 +125,7 @@
 [system.cpu1]
 type=TimingSimpleCPU
 children=dtb interrupts isa itb tracer
+branchPred=Null
 checker=Null
 clock=500
 cpu_id=1
@@ -1001,25 +1003,27 @@
 
 [system.physmem]
 type=SimpleDRAM
+activation_limit=4
 addr_mapping=openmap
 banks_per_rank=8
 clock=1000
 conf_table_reported=false
 in_addr_map=true
-lines_per_rowbuffer=64
-mem_sched_policy=fcfs

Re: [gem5-dev] Review Request: ruby: augment network to support functional accesses

[Beckmann, Brad]

Hi Nilay,

A few more comments/responses:

- Good point about the possible hierarchy of Maybe_Stale blocks.  My suggestion 
is to check that you only have one Maybe_Stale block in the situation where you 
have to satisfy a functional read with a Maybe_Stale block.  Only in the 
situation where you have multiple Maybe_Stale blocks do you fail the functional 
read.
- If you were to use the flat list approach, I believe you would avoid having 
to touch SLICC or the network.  I agree that you still have to touch around 
half of the files that you do now, but I do think you'd see a significant 
savings in files modified and complexity.  That being said, this is your patch, 
and you're going to own it.  The final call is yours.  Selfishly I really don't 
want to see the SLICC changes because I have a huge SLICC patch in the works 
that I'm going to have to rebase based on these changes.
- In general, you need to add comments to this patch.  I identified on 
particular set of functions on ReviewBoard, but there are many other places 
that comments would be appropriate.  

Brad


 -Original Message-
 From: gem5-dev-boun...@gem5.org [mailto:gem5-dev-
 boun...@gem5.org] On Behalf Of Nilay Vaish
 Sent: Sunday, October 07, 2012 10:24 AM
 To: gem5 Developer List
 Subject: Re: [gem5-dev] Review Request: ruby: augment network to support
 functional accesses
 
 On Sun, 7 Oct 2012, Andreas Hansson wrote:
 
  Hi guys,
 
  I am very much inclined to support Brad's approach, which doesn't care
  about the physical topology of the interconnect.
 
  Also, I don't want to de-rail the discussion, but an idea that I came
  to think of based on all my previous NoC work, do you really need to
  enquire the router network at all? Isn't the state always determined
  what the controllers and end-points see? What happens if the network
  only sees packets and has no clue about the actual higher-level
  messages (which is the case in plenty real NoC implementations)?
 
 
 There are several things that I believe you are missing out on.
 
 * The claim that the network does not need to enquired at all is incorrect. 
 It is
 possible that the data is in some packet in the network, and hence the
 network buffers need to be searched for that packet.
 Secondly, it seems to me that the network hierarchy it self can store some
 information that is required for making a functional access. I have not proven
 this yet.
 
 * A real NoC implementation does not support functional accesses. Anyway,
 I am not assuming any particular structure on the packets themselves, except
 that they provide a function for making a functional read/write access.
 Changes have been made to the higher level messages to support those
 functions.
 
 * I have stated before that I am not opposed to having flat list of buffers. 
 But
 it is not the approach that I prefer.
 
 --
 Nilay
 ___
 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: ruby: augment network to support functional accesses

[Beckmann, Brad]

 -Original Message-
 From: Nilay Vaish [mailto:ni...@cs.wisc.edu]
 Sent: Sunday, September 30, 2012 3:03 PM
 To: Beckmann, Brad
 Cc: Default
 Subject: RE: Review Request: ruby: augment network to support functional
 accesses
 
 On Fri, 28 Sep 2012, Beckmann, Brad wrote:
 
  I am assuming that only other buffers are the ones in the
  cache/directory/dma/ controllers. A separate call is made to
  functionally access these buffers.
 
 
  As you already know, I'm in favor of just creating a list of message
  buffers by modifying the MessageBuffer constructor.  After seeing
  the number of files you had to change with this existing patch, I'm
  further convinced that is the better approach.  This current patch
  seems quite hackish, and adding this support to Garnet is only going to
 be uglier.
  What can I do to convince you that the MessageBuffer approach is
 better?
  Or in other words, can you explain exactly what you don't like about
  the MessageBuffer approach?
 
 
  I think that going via network is better. Firstly, the list that
  would need to be created for accessing the buffers in the memory
  system, already exists as part of the network hierarchy we have.
  Secondly, it seems to that it would easier to debug if traverse the
  network in a structured manner rather than traversing a flat list.
 
 
  How is traversing the network plus calling all controllers to update
  their message buffers easier than just creating a flat list?
  Precedence in the simulator is that creating a flat list is better.
  For example, to drain the system, the flat list of SimObjects is
  traversed, not the configuration graph.
 
 
 I would be surprised if that is the case. I certainly would not create a
 new structure when one already exists, unless the new structure allows for
 some operation that could not have been possible otherwise.
 
 --
 Nilay

But the structure doesn't already exist...that's my point.  We only have the 
network structure, which is a graph data structure of a whole bunch of things, 
including *some* MessageBuffers.  Other MessgeBuffers are embedded within the 
controllers and are inaccessible by the network.  Overall, you have to deal 
with a bunch of complicated data structures with this strategy.  Meanwhile the 
flat list of MessageBuffers is simple.

Brad



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

Re: [gem5-dev] Review Request: ruby: augment network to support functional accesses

[Beckmann, Brad]

Comments below:

  I have a couple questions:
  - Why do you modify the msg.sm files?  It seems unecessary.
 
 Each class that inherits from the Message/NetworkMessage class can
 potentially hold the address, datablock that needs to be accessed
 functionally. The question here is what assumptions do we want to make on
 these classes. I am trying to strive for a solution where we do not have any
 restrictions. For example, can we assume that each of these classes will have
 exactly one data block?

Yes, this is a tradeoff of flexibility vs. elegance.  Certainly Ruby/Slicc has 
precedence to favor the former.  I'm not excited to have to modify all msg.sm 
files to support functional accesses, but maybe I/we were fooling ourselves 
earlier that support functional accesses could be relatively invisible to the 
slicc programmer.  This change puts that hope to rest.  Oh well.  I don't want 
to sacrifice flexibility.


 
 
  - How do you handle functional writes to message buffers no part of the
 network?
 
 I am assuming that only other buffers are the ones in the
 cache/directory/dma/ controllers. A separate call is made to functionally
 access these buffers.
 
 
  As you already know, I'm in favor of just creating a list of message
  buffers by modifying the MessageBuffer constructor.  After seeing the
  number of files you had to change with this existing patch, I'm further
  convinced that is the better approach.  This current patch seems quite
  hackish, and adding this support to Garnet is only going to be uglier.
  What can I do to convince you that the MessageBuffer approach is better?
  Or in other words, can you explain exactly what you don't like about the
  MessageBuffer approach?
 
 
 I think that going via network is better. Firstly, the list that would
 need to be created for accessing the buffers in the memory system, already
 exists as part of the network hierarchy we have. Secondly, it seems to
 that it would easier to debug if traverse the network in a structured
 manner rather than traversing a flat list.
 

How is traversing the network plus calling all controllers to update their 
message buffers easier than just creating a flat list?  Precedence in the 
simulator is that creating a flat list is better.  For example, to drain the 
system, the flat list of SimObjects is traversed, not the configuration graph.  

Brad

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

Re: [gem5-dev] Review Request: ruby: reset timing after cache warm up

[Beckmann, Brad]

 
 Is there no other way Ruby could restore the cache state without advancing
 time?

No.  Setting ruby state requires you to step through the necessary transient 
states and there is no clear way to know when all those transient states have 
been completely stepped through without waiting for the eventqueue to be empty.

Brad


 
 
 - Andreas
 
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.gem5.org/r/1435/#review3525
 ---
 
 
 On Sept. 24, 2012, 5:53 p.m., Nilay Vaish wrote:
 
  ---
  This is an automatically generated e-mail. To reply, visit:
  http://reviews.gem5.org/r/1435/
  ---
 
  (Updated Sept. 24, 2012, 5:53 p.m.)
 
 
  Review request for Default.
 
 
  Description
  ---
 
  Changeset 9249:4b5ef2c0dbd4
  ---
  ruby: reset timing after cache warm up Ruby system was recently
  converted to a clocked object. Such objects maintain state related to
  the time that has passed so far. During the cache warmup, Ruby system
  changes its own time and the global time. Later on, the global time is
  restored. So Ruby system also needs to reset its own time.
 
 
  Diffs
  -
 
src/mem/ruby/system/System.cc 73c3eb0dd733
src/sim/clocked_object.hh 73c3eb0dd733
 
  Diff: http://reviews.gem5.org/r/1435/diff/
 
 
  Testing
  ---
 
 
  Thanks,
 
  Nilay Vaish
 
 
 
 ___
 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: ruby: adds reset function to Ruby memory controllers

[Beckmann, Brad]

Hi Nilay,

I suspect I won’t have a chance to look at it for a while, but I believe you 
have an expert right there in Madison.  Jason should know that patch well, so 
hopefully he can help.  If I had to guess, I suspect that the problem involves 
specifying the num-dir to be greater than 1.  We probably haven’t tested that 
in a while.

Brad


From: Nilay Vaish [mailto:nore...@reviews.gem5.org] On Behalf Of Nilay Vaish
Sent: Wednesday, August 01, 2012 4:22 PM
To: Nilay Vaish; Beckmann, Brad; Default
Subject: Re: Review Request: ruby: adds reset function to Ruby memory 
controllers

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




I was trying to run the following command --



./build/X86/gem5.fast ./configs/example/ruby_random_test.py -n 64 
--topology=Mesh --num-l2caches=64 --num-dir=64



but I got a segmentation fault while the memory controller was being

registered. It first appears with revision 9103:956796e06b7f. Brad, can you 
look into this issue?


- Nilay


On July 2nd, 2012, 10:43 p.m., Brad Beckmann wrote:
Review request for Default.
By Brad Beckmann.

Updated July 2, 2012, 10:43 p.m.

Description

Changeset 9076:11422560e100

---

ruby: adds reset function to Ruby memory controllers


Diffs

  *   src/mem/ruby/system/MemoryControl.hh 
(d8e5ca139d7c24eeb665ac0aab41e180886278cb)
  *   src/mem/ruby/system/MemoryControl.cc 
(d8e5ca139d7c24eeb665ac0aab41e180886278cb)
  *   src/mem/ruby/system/RubyMemoryControl.hh (PRE-CREATION)
  *   src/mem/ruby/system/RubyMemoryControl.cc (PRE-CREATION)
  *   src/mem/ruby/system/System.hh (d8e5ca139d7c24eeb665ac0aab41e180886278cb)
  *   src/mem/ruby/system/System.cc (d8e5ca139d7c24eeb665ac0aab41e180886278cb)

View Diffhttp://reviews.gem5.org/r/1288/diff/


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

Re: [gem5-dev] Review Request: Ruby: convert cache memory stats to gem5's style

[Beckmann, Brad]

I agree there are a lot of good reasons why we should eventually move all ruby 
stats to gem5 stats.  I just want to make sure we provide the same information 
in the same concise format.  When doing protocol performance debugging, we 
really depend on those stats.

Brad


 -Original Message-
 From: Nilay Vaish [mailto:ni...@cs.wisc.edu]
 Sent: Wednesday, July 18, 2012 4:48 AM
 To: Beckmann, Brad
 Cc: Default
 Subject: Re: Review Request: Ruby: convert cache memory stats to gem5's
 style
 
 On Tue, 10 Jul 2012, Brad Beckmann wrote:
 
 
  ---
  This is an automatically generated e-mail. To reply, visit:
  http://reviews.gem5.org/r/1293/#review3076
  ---
 
 
  Nilay, can you hold off checking this patch in until I commit my
  changes.  We have a lot of internal code that uses the current Cache
  Profiler that I'll need to change.  I'd rather not do that in the next
  few weeks.
 
  This patch reminds me of a larger question that is worth revisiting.
  Is now the time to convert Ruby stats to gem5 stats, since gem5 stats
  are now python objects and can potentially be outputted in any format.
  The last half of that statement may be a streach, so please correct me
  if that's untrue.  As you know, I've been relucant to convert Ruby
  stats to gem5 stats because many Ruby stats are useful in the
  debugging process, and Ruby's more condense format is much more
 readable.
  Meanwhile, the default gem5 stats format is optimized for data
  extraction.  If we could use the new python support to generate an
  output file that looks a lot like the current ruby.stats file, then
  now maybe a good time to switch.  This is probably a better topic for
  a separate thread, but I wanted to mention that thought before I forgot.
 
  - Brad Beckmann
 
 
 
 One reason why I would like to convert to gem5' style statistics is the 
 inability
 of reset ruby' statistics as of now. This is something that several users have
 reported in recent past.
 
 --
 Nilay
 
 


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

Re: [gem5-dev] Review Request: ruby: changes how Topologies are created

[Beckmann, Brad]

Yes, I believe Jason is going to follow up this patch with further improvements.

Brad


From: Steve Reinhardt [mailto:nore...@reviews.gem5.org] On Behalf Of Steve 
Reinhardt
Sent: Wednesday, July 04, 2012 5:25 PM
To: Steve Reinhardt; Default; Beckmann, Brad
Subject: Re: Review Request: ruby: changes how Topologies are created

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



Ship it!

In the long run I hope we can clean this up even further, but I think this is a 
step in the right direction.


- Steve


On July 2nd, 2012, 10:41 p.m., Brad Beckmann wrote:
Review request for Default.
By Brad Beckmann.

Updated July 2, 2012, 10:41 p.m.

Description

Changeset 9073:da6c24cdff99

---

ruby: changes how Topologies are created



Instead of just passing a list of controllers to the makeTopology function

in src/mem/ruby/network/topologies/Topo.py we pass in a function pointer

which knows how to make the topology, possibly with some extra state set

in the configs/ruby/protocol.py file. Thus, we can move all of the files

from network/topologies to configs/topologies. A new class BaseTopology

is added which all topologies in configs/topologies must inheirit from and

follow its API.


Diffs

  *   configs/example/ruby_direct_test.py 
(d8e5ca139d7c24eeb665ac0aab41e180886278cb)
  *   configs/example/ruby_fs.py (d8e5ca139d7c24eeb665ac0aab41e180886278cb)
  *   configs/example/ruby_mem_test.py 
(d8e5ca139d7c24eeb665ac0aab41e180886278cb)
  *   configs/example/ruby_network_test.py 
(d8e5ca139d7c24eeb665ac0aab41e180886278cb)
  *   configs/example/ruby_random_test.py 
(d8e5ca139d7c24eeb665ac0aab41e180886278cb)
  *   configs/example/se.py (d8e5ca139d7c24eeb665ac0aab41e180886278cb)
  *   configs/ruby/MESI_CMP_directory.py 
(d8e5ca139d7c24eeb665ac0aab41e180886278cb)
  *   configs/ruby/MI_example.py (d8e5ca139d7c24eeb665ac0aab41e180886278cb)
  *   configs/ruby/MOESI_CMP_directory.py 
(d8e5ca139d7c24eeb665ac0aab41e180886278cb)
  *   configs/ruby/MOESI_CMP_token.py (d8e5ca139d7c24eeb665ac0aab41e180886278cb)
  *   configs/ruby/MOESI_hammer.py (d8e5ca139d7c24eeb665ac0aab41e180886278cb)
  *   configs/ruby/Network_test.py (d8e5ca139d7c24eeb665ac0aab41e180886278cb)
  *   configs/ruby/Ruby.py (d8e5ca139d7c24eeb665ac0aab41e180886278cb)
  *   configs/topologies/BaseTopology.py (PRE-CREATION)
  *   configs/topologies/Cluster.py (PRE-CREATION)
  *   src/mem/ruby/network/topologies/Crossbar.py 
(d8e5ca139d7c24eeb665ac0aab41e180886278cb)
  *   src/mem/ruby/network/topologies/Mesh.py 
(d8e5ca139d7c24eeb665ac0aab41e180886278cb)
  *   src/mem/ruby/network/topologies/MeshDirCorners.py 
(d8e5ca139d7c24eeb665ac0aab41e180886278cb)
  *   src/mem/ruby/network/topologies/Pt2Pt.py 
(d8e5ca139d7c24eeb665ac0aab41e180886278cb)
  *   src/mem/ruby/network/topologies/SConscript 
(d8e5ca139d7c24eeb665ac0aab41e180886278cb)
  *   src/mem/ruby/network/topologies/TopologyCreator.py (PRE-CREATION)
  *   src/mem/ruby/network/topologies/Torus.py 
(d8e5ca139d7c24eeb665ac0aab41e180886278cb)
  *   src/python/m5/SimObject.py (d8e5ca139d7c24eeb665ac0aab41e180886278cb)

View Diffhttp://reviews.gem5.org/r/1285/diff/


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

Re: [gem5-dev] Review Request: ruby: memory controllers now inherit from an abstract MemoryControl class

[Beckmann, Brad]

Good question.  Probably one that is easier answered once a detailed classic 
memory controller is checked in.  That may be a good incremental task on the 
way to merging MessageBuffers and Ports.

Brad


From: Steve Reinhardt [mailto:nore...@reviews.gem5.org] On Behalf Of Steve 
Reinhardt
Sent: Wednesday, July 04, 2012 5:27 PM
To: Steve Reinhardt; Default; Beckmann, Brad
Subject: Re: Review Request: ruby: memory controllers now inherit from an 
abstract MemoryControl class

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



Ship it!

A little off topic, but this makes me wonder... are we ever going to be able to 
merge ruby and classic memory controller models?  It seems like that would be 
useful.


- Steve


On July 2nd, 2012, 10:43 p.m., Brad Beckmann wrote:
Review request for Default.
By Brad Beckmann.

Updated July 2, 2012, 10:43 p.m.

Description

Changeset 9075:3b3c9db76ebc

---

ruby: memory controllers now inherit from an abstract MemoryControl class


Diffs

  *   src/mem/ruby/system/MemoryControl.hh 
(d8e5ca139d7c24eeb665ac0aab41e180886278cb)
  *   src/mem/ruby/system/MemoryControl.cc 
(d8e5ca139d7c24eeb665ac0aab41e180886278cb)
  *   src/mem/ruby/system/MemoryControl.py 
(d8e5ca139d7c24eeb665ac0aab41e180886278cb)
  *   src/mem/ruby/system/RubyMemoryControl.hh (PRE-CREATION)
  *   src/mem/ruby/system/RubyMemoryControl.cc (PRE-CREATION)
  *   src/mem/ruby/system/RubyMemoryControl.py (PRE-CREATION)
  *   src/mem/ruby/system/SConscript (d8e5ca139d7c24eeb665ac0aab41e180886278cb)
  *   src/mem/slicc/symbols/StateMachine.py 
(d8e5ca139d7c24eeb665ac0aab41e180886278cb)

View Diffhttp://reviews.gem5.org/r/1287/diff/


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

Re: [gem5-dev] Memory controller is Ruby systems

[Beckmann, Brad]

Hi Andreas,

I'm a bit confused.  Physmem (now a simple memory) is still used by Ruby as a 
backing store and RubyPort.cc still performs functional accesses on it.  Since 
Ruby can't fully support functional access this second architectural version 
of memory is still needed.  It is not just a MemObject used during 
configuration.  Therefore I don't think 1) is a solution.

As far as 2) goes, I think it would be best if we came up with an interface 
that the memory controllers already used by Ruby can be used by the classic 
model.  Here at AMD we have several different memory controllers that tie into 
the current MessageBuffer interface.  Actually we have a patch that makes that 
better virtualizes that interface.  I have it on my to do list to post that 
patch.  If you're interested, I'll try to get that out there soon.

Brad


 -Original Message-
 From: gem5-dev-boun...@gem5.org [mailto:gem5-dev-
 boun...@gem5.org] On Behalf Of Andreas Hansson
 Sent: Thursday, May 31, 2012 6:27 AM
 To: gem5 Developer List
 Subject: [gem5-dev] Memory controller is Ruby systems
 
 Hi all,
 
 In our current work on memory controller models I have had another look at
 the gem5 vs Ruby view of memories, and one thing I stumbled upon is the
 following:
 
 In e.g. simple-timing-ruby.py we create something called physmem (just a
 simple memory) with default parameters, however it is not connected to
 anything and just a child of the system. When we call Ruby.create_system,
 this uses system.memories.unproxy(system) to determine the total physical
 memory size, but that's all. In other words, we create a MemObject, leave it
 dangling, and then just have it hanging there to represent a scalar. This
 causes the controller to fatal saying it is unconnected (and overall does not
 strike me as a very good design).
 
 I see two solutions:
 
 
 1.   Do not instantiate a memory controller and leave it dangling. Instead
 pass a size parameter to Ruby.create_system and check that
 system.memories is []
 
 2.   Do it the proper way and connect the memory controllers through Ruby
 i.e. Ruby replaces the interconnect, but leaves the actual memory controller
 on the outside (there was a PPT being circulated roughly a year ago with a
 proposal from Ali and myself to do this).
 
 Can I go ahead and implement 1 as a quick fix? Do you Ruby Ninjas out there
 see any problems with this?
 
 Thanks,
 
 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] Review Request: ARM: Enable Ruby functionality with ARM FS

[Beckmann, Brad]

Sorry for the much delayed response here.  I've been too selective reading the 
gem5-dev list lately.

So if I understand correctly, the ARM FS boot loader maps to some higher 
portion of the address space and you would like to model the accesses to this 
boot loader ROM through Ruby.  Is that correct?  I'm a bit confused with the 
comment that the maximum memory supported by Ruby is 172 MB.  That certainly is 
not true.

So it appears from the patch that the CPU accesses to the boot loader don't go 
thru Ruby, but rather go through the pio bus.  Only the dma reads and writes 
from the boot loader go through Ruby.  Does that analysis seem correct to you?  
Without testing the patch myself, I can't say for sure, but think that is 
what's happening here.  If you view the boot loader accesses as being 
non-performance critical, then the current simple solution is how I would do 
it.  However, if want *all* those accesses going through Ruby, then Ruby will 
have to support multiple address spaces.

Supporting multiple address spaces in Ruby is something I would like to see 
happen, but it will be a substantial change.  It requires supporting 
non-cacheable accesses and more powerful mapping functions in the protocol 
files.  Currently only one protocol, MOESI_hammer, supports non-cacheable 
accesses and even that hasn't been fully flushed out.  Improving the mapping 
functions requires better coordination between the python config files and 
Ruby.  I don't have a clear idea of how to do it, but I'm happy to discuss 
ideas.

Brad


 -Original Message-
 From: gem5-dev-boun...@gem5.org [mailto:gem5-dev-
 boun...@gem5.org] On Behalf Of Andrew Cebulski
 Sent: Friday, May 18, 2012 2:01 PM
 To: Default; Andreas Hansson; Andrew Cebulski
 Subject: Re: [gem5-dev] Review Request: ARM: Enable Ruby functionality
 with ARM FS
 
 
 
  On May 18, 2012, 6:12 a.m., Andreas Hansson wrote:
   Conceptually I would very much like to see the patch being flipped
 around, i.e. not ARM FS on Ruby, but how to make Ruby work with ARM FS,
 and preferably having a more flexible memory map. The main goal would be
 to run the same images/kernel on different memory systems. Would this be
 possible?
 
  Andreas Hansson wrote:
  To clarify, I was not referring to the name of the patch, but to the
 changes made. In other words, I would propose to change Ruby to be able to
 deal with the memory map...not the other way round.
 
 Right, I understand...I should have commented with that change too.  That is
 definitely the final goal, but I'm still waiting on suggestions and/or 
 pointers
 on how this can be done.  I'm new to the Ruby model (and Ruby itself), and
 have not had time to ramp up on how it works and handles memory.
 
 My current solution is definitely a temporary hack.  Submitting it here on
 the review board will hopefully get more people thinking about a permanent
 solution without the current memory limitations (172MB).  That and getting
 Ruby working with O3CPU in ARM FS.  That should work even with 172MB of
 memory (it does at least with the classic system).  When I get a chance, I can
 run a debug trace and email the it to the list.
 
 
 - Andrew
 
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.gem5.org/r/1191/#review2708
 ---
 
 
 On May 18, 2012, 8:36 a.m., Andrew Cebulski wrote:
 
  ---
  This is an automatically generated e-mail. To reply, visit:
  http://reviews.gem5.org/r/1191/
  ---
 
  (Updated May 18, 2012, 8:36 a.m.)
 
 
  Review request for Default.
 
 
  Description
  ---
 
  These are the changes I made to get ARM FS working with Ruby.  Most
 notably, I had to make the memory contiguous by putting the physmem and
 nvmem together, otherwise Ruby would not handle them correctly.  Details
 here on the mailing list:
 http://permalink.gmane.org/gmane.comp.emulators.m5.users/10440
 
  This required shrinking physmem from 256MB to 172MB, then placing
 nvmem at address 172MB.  Next, the boot loader has to be recreated with
 the Makefile under the system directory, changing the address to
 0x0C00.
 
  Hopefully, at the very least, this will help others start testing out ARM FS
 with Ruby.
 
 
  Diffs
  -
 
build_opts/ARM_MESI_CMP_directory PRE-CREATION
build_opts/ARM_MOESI_CMP_directory PRE-CREATION
build_opts/ARM_MOESI_CMP_token PRE-CREATION
build_opts/ARM_MOESI_hammer PRE-CREATION
configs/common/Benchmarks.py f681719e2e99
configs/common/FSConfig.py f681719e2e99
configs/example/ruby_fs.py f681719e2e99
src/dev/arm/RealView.py f681719e2e99
system/arm/simple_bootloader/Makefile f681719e2e99
 
  Diff: http://reviews.gem5.org/r/1191/diff/
 
 
  Testing
  ---
 
  Currently, I've tested this successfully with the 

Re: [gem5-dev] Review Request: X86: Split Condition Code register

[Beckmann, Brad]

Thanks Gabe and Nilay for restarting this conversation.

So I don't understand all the issues here, but it seems like Gabe's concern is 
the effort required to support Nilay's proposal, correct?  If so, then if Nilay 
is willing to make all required changes to support his proposal, would that be 
ok?  

Brad


 -Original Message-
 From: gem5-dev-boun...@gem5.org [mailto:gem5-dev-
 boun...@gem5.org] On Behalf Of Gabriel Michael Black
 Sent: Tuesday, May 15, 2012 8:29 PM
 To: gem5-dev@gem5.org
 Subject: Re: [gem5-dev] Review Request: X86: Split Condition Code register
 
 The call sight isn't wildly different, except that setCCFlagsBits will have 
 fewer
 parameters and won't have to put some of them on the stack.
 A lot of the complexity comes from breaking up setCCFlagsBits so that you
 have lots of function signatures, curly brackets, return lines, etc., and some
 functions which duplicate logic operating on the emulation or non-emulation
 version of a flag.
 
 Gabe
 
 Quoting Nilay Vaish ni...@cs.wisc.edu:
 
  What I proposed --
 
  zaps = setZaps(zaps,ext);
  ecf = setEcf(ecf,ext);
 
  What I believe Gabe proposed --
 
  temp = setCCFlagsBits(zaps|ecf,ext);
  zaps = temp  zapsmask
  ecf = temp  ecfmask;
 
  As of now I don't seen any merit that the second approach has over the
  first one. Gabe, would you explain why do you want to go with the
  second one?
 
  --
  Nilay
 
 
  On Fri, 11 May 2012, Gabe Black wrote:
 
  We're debating how the code in the patch should be organized. My
  position is still that the function which computes condition codes
  should not be split up and doesn't actually need to change. It sounds
  like Steve agrees.
 
  Gabe
 
  On 05/10/12 13:31, Beckmann, Brad wrote:
  What is the status of this patch?  Nilay, are you trying to address
  Gabe's concerns or are you having a problem defining a solution that
  meets both your and Gabe's requirements?  I don't understand the
  specifics of this patch, but I want to do whatever possible to find
  a solution.  This is a critical fix for the O3
  x86 CPU model.
 
  Thanks,
 
  Brad
  ___
  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] Debugging New Translating Ports / PortProxy

[Beckmann, Brad]

Hi Joel,

Sorry for the slow reply...is this still an issue?  Since you and Nilay are now 
working on the same floor, did you resolve this locally instead of via email?

Brad


 -Original Message-
 From: gem5-dev-boun...@gem5.org [mailto:gem5-dev-boun...@gem5.org]
 On Behalf Of Joel Hestness
 Sent: Monday, April 09, 2012 3:56 PM
 To: gem5 Developer List
 Subject: Re: [gem5-dev] Debugging New Translating Ports / PortProxy
 
 Hey guys,
   I've dug into this some more, and this challenge looks pretty complex.
  For some detail on what's happening, I'm trying to integrate another 
 simulator
 in with gem5, and I need to use functional accesses to get data that this 
 other
 simulator needs in the functional aspects of it's simulation.
 
   As I mentioned previously, when using Ruby, if a cache line happens to be in
 the busy state on a functional access (e.g. if it is being passed between 
 caches
 in most protocols), the RubyPort doesn't know how to grab the data on a
 functional read, or which data to update on a functional write.  The current
 code handles read-write and read-only data in the caches, but doesn't handle
 this busy state.
 
 @Brad, Nilay:
   I tracked down some conversation you've had about functional access in a
 previous thread (here:
 http://www.mail-archive.com/gem5-dev@m5sim.org/msg12120.html
 [gem5-dev] Functional Memory
 Accesses in Ruby), in which you articulate the exact problems that I'm 
 dealing
 with here.  Unfortunately, the assumption that Ruby should not handle
 functional access when a cache line is in an intermediate state has given me
 some major problems with the integration I'm working on (at least
 5 of my 12 preliminary benchmarks).
 
   I'm hoping you guys could clarify a couple things for me:
1) It's not clear to me whether the messages passed between cache
 controllers contain copies of the data being transferred, or if they just 
 contain
 pointers to locations which contain the data to be transferred.
  This is important if, during a functional write in an intermediate state, 
 there is
 a copy of the data that is not pointed to by the caches that are being 
 updated.
 Can you clarify this?
 
2) Can you also clarify what the RubyPort::M5Port variable access_phys_mem
 is supposed to indicate?  If set, does this mean that the physical memory
 actually contains the most up-to-date (possibly even dirty cache line) data?
 
   Thanks!
   Joel
 
 
 
  Other scribblings for the record 
   Making this more complex is that in order for this functional access code to
 work with other Ruby protocols, this solution will have to be generic to 
 handle
 different types of intermediate states.  I think the correct way for this to 
 work is
 the following:
- On functional reads, find the cache(s) that contains the most recent data
 (e.g. modified, exclusive or shared), and read the portion of the line that 
 the
 functional access needs.  If the line does not exist in caches, just read from
 memory.
- On functional writes, find the cache(s) that contains the most recent 
 data
 (e.g. modified, exclusive or shared), and write the portion of the line that 
 the
 functional access needs.  If the write switches the cache line's state (e.g.
 exclusive to modified), update the appropriate state.
  If the line does not exist in caches, simply forward the request on to memory
 (this includes if we update lines in the shared state that aren't dirty).
 
 
 
 
 On Mon, Mar 19, 2012 at 9:41 AM, Andreas Hansson
 andreas.hans...@arm.comwrote:
 
  As we already saw with one of the Ruby regressions, the changes in the
  port proxies did expose similar issues already (see changeset
  f2ac0bca75df). In short, I am fairly confident that the port proxies
  are not the source of the problem.
 
  I think it boils down to the access permissions in Ruby, but wouldn't
  know how/what to change. Nilay?
 
  Andreas
 
 
  -Original Message-
  From: gem5-dev-boun...@gem5.org [mailto:gem5-dev-boun...@gem5.org]
 On
  Behalf Of Gabe Black
  Sent: 19 March 2012 06:42
  To: gem5-dev@gem5.org
  Subject: Re: [gem5-dev] Debugging New Translating Ports / PortProxy
 
  Somewhat tangential to the problem you're having, the SE/FS merge and
  the change to how ports work were pretty much entirely unrelated, they
  just happened to go in around the same time. What you describe sounds
  like it could be from the ports change, but, at least from what you've
  described, I don't think the SE/FS merge is a factor.
 
  Gabe
 
  On 03/18/12 14:54, Nilay Vaish wrote:
   On Fri, 16 Mar 2012, Joel Hestness wrote:
  
   Hey guys,
I just updated my repo to the gem5 head, and I'm trying to merge
   my old patches.  It looks like the TranslatingPort that used to be
   the O3CPU funcport has changed, and I run into a fatal when trying
   to run the new code.
  
I'm trying to run simulation with x86 O3CPU, full_system=False (SE
   mode), and using a Ruby cache hierarchy.  With the 

Re: [gem5-dev] Review Request: Ruby X86: problem in setting DMA port, related to the changeset 8850

[Beckmann, Brad]

I propose that Nilay checks in the current patch so that all of us Ruby user 
can continue to use gem5 in x86 FS mode.  Supporting config and pio requests in 
Ruby will take some time and ruby_fs hasn't been working for several weeks now.

Brad


 -Original Message-
 From: gem5-dev-boun...@gem5.org [mailto:gem5-dev-boun...@gem5.org]
 On Behalf Of Nilay Vaish
 Sent: Tuesday, April 03, 2012 10:27 AM
 To: Nilay Vaish; Andreas Hansson; Default
 Subject: Re: [gem5-dev] Review Request: Ruby X86: problem in setting DMA
 port, related to the changeset 8850
 
 
 
  On March 26, 2012, 3:23 a.m., Andreas Hansson wrote:
   Is it not possible to use the Ruby sequencers for all the connections to 
   the
 DMA devices, i.e. config, pio and dma?
 
  Nilay Vaish wrote:
  I think Ruby, as of now, cannot allow pio accesses to flow through it. 
  I have
 talked to Brad
  about this before, and it seems to me that current implementation would
 have to be enhanced.
  I don't know what config port is about.
 
  Andreas Hansson wrote:
  I was just thinking...if the config and pio request and responses do 
  not go
 through Ruby, then can we not do the same for the dma port requests and
 responses? Since Ruby does not do general memory-mapped
 requests/responses for the former, we could simply connect also the dma port
 to the bus that is used for the config and pio port, could we not?
 
  Nilay Vaish wrote:
  I believe we can, but I don't have a say on what should be preferred.
 
  Nilay Vaish wrote:
  Andreas, can you comment on how these three types of accesses differ
 from each other?
  With a better picture, I might be able to able to allow pio and config
 requests to go
  through Ruby.
 
  Andreas Hansson wrote:
  The pio and config port are memory-mapped slave ports (much like a
 memory), but instead of storing data they read/write to registers that affect
 the behaviour of the device. Hence, they receive requests and send out
 responses.
 
  The dma port is a master port (much like a CPU inst/data port), and it
 sends out read/write requests and expects them to be routed to a slave based
 on the address, and responses to come back when necessary.
 
  Let me know if there is more information you would like about their
 functionality and the assumptions.
 
 Can you draw a diagram to depict what you wrote?
 
 
 - Nilay
 
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.gem5.org/r/1102/#review2378
 ---
 
 
 On March 24, 2012, 1:27 p.m., Nilay Vaish wrote:
 
  ---
  This is an automatically generated e-mail. To reply, visit:
  http://reviews.gem5.org/r/1102/
  ---
 
  (Updated March 24, 2012, 1:27 p.m.)
 
 
  Review request for Default.
 
 
  Description
  ---
 
  Changeset 8918:e1988ccf8001
  ---
  Ruby X86: problem in setting DMA port, related to the changeset 8850 I
  think since the dma port is assigned twice (once in SouthBridge.py,
  and once by Ruby somewhere) an extra port gets created which has no
  peer port. This results in a segmentation fault when a simulation is
  started. The posted patch solves the problem, but it is not the
  solution I am looking for. Andreas, do you have some idea how to
  handle this issue?
 
 
  Diffs
  -
 
configs/common/FSConfig.py 7d95b650c9b6
src/dev/x86/Pc.py 7d95b650c9b6
src/dev/x86/SouthBridge.py 7d95b650c9b6
 
  Diff: http://reviews.gem5.org/r/1102/diff/
 
 
  Testing
  ---
 
 
  Thanks,
 
  Nilay Vaish
 
 
 
 ___
 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] x86 Checkpoint Restore Trouble

[Beckmann, Brad]

Hmm...timing cpu restoring a checkpoint created by the atomic cpu used to work? 
 What changed with regards to interrupts broke it?

It would be great if we could maintain atomic - timing checkpoint capability.  
It is really useful to use the atomic cpu to fast-forward to an interesting 
point in an application, take a checkpoint, then use that checkpoint across 
multiple experiments using the timing cpu.

Brad



 -Original Message-
 From: gem5-dev-boun...@gem5.org [mailto:gem5-dev-boun...@gem5.org]
 On Behalf Of Nilay Vaish
 Sent: Tuesday, April 03, 2012 6:51 PM
 To: gem5 Developer List
 Subject: Re: [gem5-dev] x86 Checkpoint Restore Trouble
 
 Joel, you might know that system being restored from a check point starts with
 an atomic cpu by default. I think the problem you are facing is in 
 initializing a
 timing CPU. IIRC, the interrupt controller is moved from atomic CPU to timing
 CPU after X number of ticks. You might want to try restoring with a timing CPU
 to begin with (use option --restore-cpu-type).
 But I think you will run in to problem there as well if the checkpoint was
 created using an atomic CPU as the check pointed state is a super set of the
 architectural state and depends on the CPU type in use.
 
 You might want to create check points using the timing CPU it self.
 
 --
 Nilay
 
 On Tue, 3 Apr 2012, Joel Hestness wrote:
 
  Hey guys,
   I've tried searching around, but I'm having trouble finding any help
  on this.  Anyone have insights or pointers?  Is checkpoint restore
  supposed to be working?
 
  ---
  joel@vein:~/research/gem5/gem5-latest$ ./build/X86/gem5.debug
  ./configs/example/fs.py --take-checkpoints=50,1
  gem5 Simulator System.  http://gem5.org
  gem5 is copyrighted software; use the --copyright option for details.
 
  gem5 compiled Apr  3 2012 12:11:41
  gem5 started Apr  3 2012 18:13:38
  gem5 executing on vein
  command line: ./build/X86/gem5.debug ./configs/example/fs.py
  --take-checkpoints=50,1
  warning: add_child('terminal'): child 'terminal' already has parent
  Global frequency set at 1 ticks per second
  info: kernel located at:
  /home/joel/research/gem5/full_system_files/binaries/x86_64-vmlinux-
 2.6.28.4-smp
   0: rtc: Real-time clock set to Sun Jan  1 00:00:00 2012 Listening
  for com_1 connection on port 3458
  warn: Reading current count from inactive timer.
  0: system.remote_gdb.listener: listening for remote gdb #0 on port
  7002
  info: Entering event queue @ 0.  Starting simulation...
  warn: Don't know what interrupt to clear for console.
  warn: instruction 'wbinvd' unimplemented Writing checkpoint
  info: Entering event queue @ 50.  Starting simulation...
  ^Chack: be nice to actually delete the event here Exiting @ tick
  5559293000 because user interrupt received
  joel@vein:~/research/gem5/gem5-latest$ ./build/X86/gem5.debug
  ./configs/example/fs.py -r 1 --cpu-type=timing
  gem5 Simulator System.  http://gem5.org
  gem5 is copyrighted software; use the --copyright option for details.
 
  gem5 compiled Apr  3 2012 12:11:41
  gem5 started Apr  3 2012 18:15:08
  gem5 executing on vein
  command line: ./build/X86/gem5.debug ./configs/example/fs.py -r 1
  --cpu-type=timing
  warning: add_child('terminal'): child 'terminal' already has parent
  Global frequency set at 1 ticks per second
  info: kernel located at:
  /home/joel/research/gem5/full_system_files/binaries/x86_64-vmlinux-
 2.6.28.4-smp
   0: rtc: Real-time clock set to Sun Jan  1 00:00:00 2012 Listening
  for com_1 connection on port 3458
  *gem5.debug: build/X86/arch/x86/utility.cc:171: void
  X86ISA::initCPU(ThreadContext*, int): Assertion `interrupts' failed.*
  *Program aborted at cycle 0*
  *Aborted*
  ---
 
   For this test, I'm using changeset 8900 with Nilay's port fix patch here:
  http://reviews.gem5.org/r/1102/
   The same assertion failure happens for ruby_fs.py (and the script
  that I've derived from ruby_fs.py).
 
   Thanks!
   Joel
 
 
  --
   Joel Hestness
   PhD Student, Computer Architecture
   Dept. of Computer Science, University of Texas - Austin
  http://www.cs.utexas.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


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

Re: [gem5-dev] Review Request: Config: Change the way options are added

[Beckmann, Brad]

Nilay,

The basic problem here is that fs.py, se.py, and ruby_fs.py include a lot of 
useful functionality that people don't want to duplicate.  I don't think asking 
users to maintain separate config files is the right answer.  Instead we need 
to make these config files more modular.  Also we need to avoid unnecessarily 
moving more unrelated config parameters into common files.  Jason has some 
ideas on how to do that and I think he'll post a message soon on that topic.

The goal to share more configuration code with the regression tester is great.  
However, I think we need to do that by sharing more modules between the two, 
not moving more information into the few modules that already are.

Brad


 -Original Message-
 From: Nilay Vaish [mailto:ni...@cs.wisc.edu]
 Sent: Friday, March 30, 2012 9:33 AM
 To: Beckmann, Brad
 Cc: Steve Reinhardt; gem5 Developer List; Gabe Black
 Subject: RE: [gem5-dev] Review Request: Config: Change the way options
 are added
 
 Brad
 
 * The functions for adding options introduced by the patch could have been
 placed in se.py and fs.py. I did not do that because ruby_fs.py and fs.py have
 options in common, and to avoid duplication those options were placed in
 Options.py. And the options in se.py were also moved to Options.py so that
 a common file has all the options in it. We can always move these functions
 back in to their respective files.
 
 * Ruby's options are being added separately via function calls, so I did not 
 see
 any need to change it. I certainly feel that a lot of duplication exists 
 across
 scripts in configs/ruby directory, but it would require some thinking on how
 to combine the scripts together.
 
 * These configuration files are examples which can be used to write config
 files for a specific need. I don't know if the files in config/ change more 
 often
 that those in src/. But assuming that's true, any patches for these files that
 users maintain will need to be rebased more often than other patches. I
 suggest that users should maintain separate config files instead of modifying
 se/fs.py, so that they are not affected.
 
 * One of the things that I felt is worth spending time on, is to make
 regression tests use se/fs.py by setting options properly instead of redoing
 the work of se/fs.py. And I think it is with this aim that I posted the patch.
 
 --
 Nilay
 
 On Thu, 29 Mar 2012, Beckmann, Brad wrote:
 
  The reason I protest to this change is because I feel it is a step in
  the wrong direction.  As Steve says, the biggest pain point for us to
  maintain patches that work on top of gem5 is the configuration scripts.
  This changeset would centralize several system specific options into
  Option.py which will likely cause unnecessary conflicts when future
  parameters are added and seems to be contrast to the desire for more
  modularity.  Furthermore, the changeset uses a confusing policy where
  most system specific parameters are put in Options.py but Ruby
  protocol options still remain in their respective py config files.
  Finally, there are a few minor semantic changes in this changeset that
  just don't seem really worth it.
 
  Sorry to push back so much on this, but my recent experience with
  rebasing config files have made me leery of these sorts of changes.
 
  Brad
 
  From: Steve Reinhardt [mailto:ste...@gmail.com]
  Sent: Wednesday, March 28, 2012 5:13 PM
  To: gem5 Developer List
  Cc: Nilay Vaish; Beckmann, Brad; Gabe Black
  Subject: Re: [gem5-dev] Review Request: Config: Change the way options
  are added
 
 
  On Wed, Mar 28, 2012 at 4:11 PM, Gabe Black
 gbl...@eecs.umich.edumailto:gbl...@eecs.umich.edu wrote:
  I'm assuming Steve and Ali have already weighed the pros and cons which
 is why they were ok with it going in.
 
  Just to weigh in on this point... I approved it because it looked
  reasonable (i.e., not unreasonable), but I did not do an extensive
  cost/benefit analysis.  I didn't really think about the impact on
  existing scripts.
 
  I will mention that config script modularity is a real problem we
  have, and it would be nice to see steps toward making things more
  modular (without having lots of duplicate code).  I don't think this
  change is a step in the wrong direction, but I'm not sure if it's a
  step forward or just sideways.
 
  Steve
 
 


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

[gem5-dev] Clock Defaults

[Beckmann, Brad]

Hi All,

Mithuna Thottethodi recently pointed out that our current methodology for 
setting clock defaults is inconsistent and some of the values are unreasonable. 
 For instance, CPUs set their default clock value (gem5/src/cpu/BaseCPU.py) to 
be the same as the global simulation clock, which is 1 THz 
(gem5/src/python/m5/ticks.py).  Meanwhile, Ruby sets it's default value to be 1 
GHz (src/mem/ruby/system/RubySystem.py).  Therefore, unless your config file 
overrides these defaults, the CPUs will unrealistically run at a THz will Ruby 
drags along running three orders of magnitude slower (due to instruction 
fetches, I understand in practice it isn't quite that bad).  It seems 
unreasonable and confusing for any CPU to be setting its frequency at 1 THz.  
However, I'm not sure if setting any clock defaults in the SimObject .py files 
is the best idea since it is prone to user ignorance.

The idea we are proposing is to not set any clock defaults in the SimObject .py 
files and force the configuration scripts to set these values appropriately.  
We think this would also be amendable to later on adding a clock domain feature 
in gem5 where collections of sim objects can be assigned to separate domains 
and support features like DVFS.  Would anyone be opposed to such a change?  If 
not, we can submit a patch for review that accomplishes the first step (removes 
Sim Object .py clock defaults) and start working on the second part.

Thanks and please let us know what you think,

Brad

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

Re: [gem5-dev] Review Request: Config: Change the way options are added

[Beckmann, Brad]

The reason I protest to this change is because I feel it is a step in the wrong 
direction.  As Steve says, the biggest pain point for us to maintain patches 
that work on top of gem5 is the configuration scripts.  This changeset would 
centralize several system specific options into Option.py which will likely 
cause unnecessary conflicts when future parameters are added and seems to be 
contrast to the desire for more modularity.  Furthermore, the changeset uses a 
confusing policy where most system specific parameters are put in Options.py 
but Ruby protocol options still remain in their respective py config files.  
Finally, there are a few minor semantic changes in this changeset that just 
don't seem really worth it.

Sorry to push back so much on this, but my recent experience with rebasing 
config files have made me leery of these sorts of changes.

Brad

From: Steve Reinhardt [mailto:ste...@gmail.com]
Sent: Wednesday, March 28, 2012 5:13 PM
To: gem5 Developer List
Cc: Nilay Vaish; Beckmann, Brad; Gabe Black
Subject: Re: [gem5-dev] Review Request: Config: Change the way options are added


On Wed, Mar 28, 2012 at 4:11 PM, Gabe Black 
gbl...@eecs.umich.edumailto:gbl...@eecs.umich.edu wrote:
I'm assuming Steve and Ali have already weighed the pros and cons which is why 
they were ok with it going in.

Just to weigh in on this point... I approved it because it looked reasonable 
(i.e., not unreasonable), but I did not do an extensive cost/benefit analysis.  
I didn't really think about the impact on existing scripts.

I will mention that config script modularity is a real problem we have, and it 
would be nice to see steps toward making things more modular (without having 
lots of duplicate code).  I don't think this change is a step in the wrong 
direction, but I'm not sure if it's a step forward or just sideways.

Steve

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

Re: [gem5-dev] Review Request: O3, Ruby: Forward invalidations from Ruby to O3 CPU

[Beckmann, Brad]

If it doesn’t impact the lsq design much, would prefer a new command so that 
the code is more clear.  At the very least, there should be a comment better 
explaining what is going on and what makes the packet a snoop packet.

Brad



From: Nilay Vaish [mailto:ni...@cs.wisc.edu]
Sent: Friday, January 06, 2012 7:12 PM
To: Nilay Vaish; Beckmann, Brad; Default
Subject: Re: Review Request: O3, Ruby: Forward invalidations from Ruby to O3 CPU

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



On January 6th, 2012, 4:59 p.m., Brad Beckmann wrote:
src/mem/ruby/system/RubyPort.cchttp://reviews.m5sim.org/r/894/diff/8/?file=16993#file16993line699
 (Diff revision 8)



RubyPort::ruby_eviction_callback(const Address address)


699


Packet *pkt = new Packet(req, MemCmd::ReadExReq, -1);



Should this use a different MemCmd then ReadExReq?

The current code in cache_impl.hh reads the command from the

packet the cache just snooped upon and creates a snoop packet

with the same command. This snoop packet is received by the

lsq. In case of a ReadExReq, the cache will send a snoop

packet to the lsq. Hence, I chose this command. I did not

find any thing better in packet.cc, unless we want to define

a new command.


- Nilay


On January 4th, 2012, 1:11 p.m., Nilay Vaish wrote:
Review request for Default.
By Nilay Vaish.

Updated 2012-01-04 13:11:44

Description

O3, Ruby: Forward invalidations from Ruby to O3 CPU

This patch implements the functionality for forwarding invalidations and

replacements from the L1 cache of the Ruby memory system to the O3 CPU. The

implementation adds a list of ports to RubyPort. Whenever a replacement or an

invalidation is performed, the L1 cache forwards this to all the ports, which

is the LSQ in case of the O3 CPU.


Diffs

 *   configs/ruby/MESI_CMP_directory.py (09b482ee9ae0)
 *   configs/ruby/MI_example.py (09b482ee9ae0)
 *   configs/ruby/MOESI_CMP_directory.py (09b482ee9ae0)
 *   configs/ruby/MOESI_CMP_token.py (09b482ee9ae0)
 *   configs/ruby/MOESI_hammer.py (09b482ee9ae0)
 *   src/mem/protocol/MESI_CMP_directory-L1cache.sm (09b482ee9ae0)
 *   src/mem/protocol/MI_example-cache.sm (09b482ee9ae0)
 *   src/mem/protocol/MOESI_CMP_directory-L1cache.sm (09b482ee9ae0)
 *   src/mem/protocol/MOESI_CMP_token-L1cache.sm (09b482ee9ae0)
 *   src/mem/protocol/MOESI_hammer-cache.sm (09b482ee9ae0)
 *   src/mem/protocol/RubySlicc_Types.sm (09b482ee9ae0)
 *   src/mem/ruby/system/RubyPort.hh (09b482ee9ae0)
 *   src/mem/ruby/system/RubyPort.cc (09b482ee9ae0)
 *   src/mem/ruby/system/Sequencer.hh (09b482ee9ae0)
 *   src/mem/ruby/system/Sequencer.cc (09b482ee9ae0)

View Diffhttp://reviews.m5sim.org/r/894/diff/


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

Re: [gem5-dev] One failing Ruby regression after memory-system patches

[Beckmann, Brad]

 
 I think we should try to understand as to why this problem is occurring in 
 first
 place. Andreas, in one of the earlier emails, mentioned that these memory-
 system patches do not introduce any timing changes. The only other reason I
 can think of why this test is failing, is that these accesses did not used to 
 go
 through Ruby earlier. This seems strange, but may be that is true.
 

The problem occurs because of a race between timing requests and function 
requests that come an emulated system call that doesn't appear to have been 
modified in years.  I doubt there is anything in Andreas's patches that 
directly cause this problem.  They probably just reorder the requests in a 
particular way that now cause the rare race to occur with the hammer protocol.  
Having a functional access race with a timing writeback seems like a very rare 
situation.  I'm not surprised we haven't seen this before.

 Andreas, is it possible for you to figure out what particular change in the
 memory system is making this test fail?
 
 Whether or not that particular state can have Read_Write permissions
 depends on the protocol itself. A quick glance tells me that it might be all
 right to change the permissions in this case. We might want to switch to a
 single copy of each cache block in order to avoid this problem. Do we really
 need the data to reside in the interconnection network to carry out a
 simulation? Can we not have fake data in the network and the actual data
 always resides at one single place?
 
I'd rather not remove data from the interconnect.  That is certainly not in the 
spirit of execute at execute.  Having data exist in one single place is what 
we do today with Ruby's backing copy of physmem.  If we have data always reside 
in one single place, then we might as well remove all of Ruby's functional 
access support and go back to just sending all functional accesses to physmem.

For the particular problem we're seeing today, data is not stuck in the 
interconnection network.  Rather it is just stuck in the DRAM request queue 
that simulates the timing of the DRAM interface.  The data itself has already 
been written to DirectoryMemory.

Overall, I'm not happy with any solution that comes to my mind.  I don't like 
having to deal with these problems one-by-one, nor do I want to remove Ruby's 
functional access support.  I also don't want to have to build some sort of 
complicated mechanism that tries to identify valid data floating in any Ruby 
buffer (network, DRAM, etc.) because I don't see how one can do that without 
putting a lot of burden/restriction on the protocol writer.

Brad


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

Re: [gem5-dev] Review Request: Ruby: Resurrect Cache Warmup Capability

[Beckmann, Brad]

Ah, I understand the issue now.  Yes, your solution manipulating the event 
queue seems like it will work.

It would be nice if we could have a regression test that can test this 
functionality once you check it in.  I could imagine a further checkin 
accidently breaking this process.

Brad


 -Original Message-
 From: Nilay Vaish [mailto:ni...@cs.wisc.edu]
 Sent: Friday, December 09, 2011 8:02 AM
 To: Beckmann, Brad
 Cc: Steve Reinhardt; Ali Saidi; Gabe Black; Nathan Binkert; Default
 Subject: RE: Review Request: Ruby: Resurrect Cache Warmup Capability
 
 I thought more about this. It seems we can do it in the same manner as we
 do things in unserialize(). In the serialize() function, we can change the 
 event
 queue head, issue the cache flush requests, and then call simulate(). Once
 the caches are flushed, the event queue head is restored and the memory
 image is checkpointed.
 
 --
 Nilay
 
 On Thu, 8 Dec 2011, Nilay Vaish wrote:
 
  I was initially thinking that a flush request for line is issued along
  with it being added to the trace. But then, I realized (I might be
  wrong here), that once the system has got drained, it may no longer
 process any events.
  This means that the flush requests would actually not be processed at all.
 
  --
  Nilay
 
  On Thu, 8 Dec 2011, Beckmann, Brad wrote:
 
  I was imagining that we flush the caches during the
  serialization/checkpointing process, not before it.  I'm thinking the
  cache trace creation is the first step of the Ruby serialize
  function, then we flush the caches, and final we take the memory
  checkpoint.  Is there a reason we can do that in that order?
 
  Brad
 
 
  -Original Message-
  From: Nilay Vaish [mailto:ni...@cs.wisc.edu]
  Sent: Thursday, December 08, 2011 3:58 PM
  To: Beckmann, Brad
  Cc: Steve Reinhardt; Ali Saidi; Gabe Black; Nathan Binkert; Default
  Subject: RE: Review Request: Ruby: Resurrect Cache Warmup Capability
 
  Brad, you are right. Now that I think of it, it really does not make
  much sense to take periodic checkpoints when the simulation is in
  timing mode (and not in atomic mode) as checkpointing interferes
  with the timing.
 
  I was thinking about checkpointing the memory image. I have not been
  able to convince myself about some reasonably correct way of doing
  this. We need to flush the caches, before we can take a checkpoint.
  It appears this can only happen while the system is draining. My
  understanding of cache flushing is that it would write back the data
  to the memory and invalidate the cache line. Since the cache does
  not have the line any more, this means that we cannot have that line
  in the cache trace. It seems only the lines that have access
  permission as Read_Only can be part of the cache trace. Is my
  understanding correct?
 
  Thanks
  Nilay
 
 


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

Re: [gem5-dev] Review Request: Ruby: Resurrect Cache Warmup Capability

[Beckmann, Brad]

Switching to email.

The thing to remember is the cache trace doesn’t keep track of whether shared 
data is dirty or not.  It simply marks that address for a load request.  We 
don’t want to store dirty state in the cache since we want to make these traces 
protocol agnostic and each protocol can potentially manage dirty data 
differently.  That is why the current patch breaks those checks.

Brad



Brad, thanks for the review. I can take care of all of the things you have 
pointed

out. I'll add functions for serializing and unserializing the memory image.



But I have other questions. Is flushing the cache necessary? If we are correctly

restoring the data in the caches, I think that we can checkpoint the memory

image even with stale data. Secondly, why were those checks breaking earlier?

I picked those lines directly from the patch you had provided to Somayeh.


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

Re: [gem5-dev] Problem with MOESI_hammer protocol

[Beckmann, Brad]

Sorry for the delay.  This fix, along with a couple other minor improvements, 
have been pushed.

Brad


 -Original Message-
 From: gem5-dev-boun...@gem5.org [mailto:gem5-dev-
 boun...@gem5.org] On Behalf Of Beckmann, Brad
 Sent: Wednesday, November 30, 2011 10:45 AM
 To: Nilay Vaish
 Cc: gem5-dev@gem5.org
 Subject: Re: [gem5-dev] Problem with MOESI_hammer protocol
 
 Nilay,
 
 I am well aware of this problem and I actually already have a fix available.
 
 I'll push the fix momentarily.
 
 Brad
 
  -Original Message-
  From: Nilay Vaish [mailto:ni...@cs.wisc.edu]
  Sent: Tuesday, November 29, 2011 5:50 PM
  To: Beckmann, Brad
  Cc: gem5-dev@gem5.org
  Subject: Problem with MOESI_hammer protocol
 
  Hi Brad
 
  I am trying to boot an x86 full system with O3 and Ruby, the protocol
  being MOESI hammer. The simulation aborts due to a certain load
  request not getting fulfilled with in stipulated time. Looking at the
  trace, I gathered that three load requests got stuck in a loop. I
  think the problem is with the following transition. Can you comment
  why wakeupAllDependents might be needed in this transition. I don't
  think a request will get fulfilled / resources freed-up due to this 
  transition.
 
 
 // Transitions moving data between the L1 and L2 caches
 transition({I, S, O, M, MM}, L1_to_L2) {
   i_allocateTBE;
   gg_deallocateL1CacheBlock;
   vv_allocateL2CacheBlock;
   hp_copyFromTBEToL2;
   s_deallocateTBE;
   ka_wakeUpAllDependents;
 }
 
 
  Thanks
  Nilay
 
 
 ___
 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: Forward invalidations from Ruby to O3 CPU

[Beckmann, Brad]

Let’s move this conversation to just the email thread.

I suspect we may be talking past each other, so let’s talk about the complete 
implementations not just Ruby.  There are multiple ways one can implement the 
store portion of x86-TSO.  I’m not sure what the O3 model does, but here are a 
few possibilities:

-  Do not issue any part of the store to the memory system when the 
instruction is executed.  Instead, simply buffer it in the LSQ until the 
instruction retires, then buffer in the store buffer after retirement.  Only 
when the store reaches the head of the store buffer, issue it to Ruby.  The 
next store is not issued to Ruby until the previous store head completes, 
maintaining correct store ordering.

-  Do not issue any part of the store to the memory system when the 
instruction is executed.  Instead, simply buffer it in the LSQ until the 
instruction retires.   Once it retires and enters the store buffer and we issue 
the address request to Ruby (no L1 data update).  Ruby forwards 
probes/replacemetns to the store buffer and if the store buffer sees a 
probe/replacement to an address who’s address request has already completed, 
the store buffer reissues the request.  Once the store reaches the head of the 
store buffer, double check with Ruby that write permissions still exist in the 
L1.

-  Issue the store address (no L1 data update) to Ruby when the 
instruction is executed.  When it retires, it enters the store buffer.  Ruby 
forwards probes/replacemetns to the LSQ+store buffer and if either sees a 
probe/replacement to an address who’s address request has already completed, 
the request reissues (several policies exist on when to reissue the request).  
Once the store reaches the head of the store buffer, double check with Ruby 
that write permissions still exist in the L1.

Do those scenarios make sense to you?  I believe we can implement any one of 
them without modifying Ruby’s core functionality.  If you are envisioning or if 
O3 implements something completely different, please let me know.

Brad



From: Brad Beckmann [mailto:brad.beckm...@amd.com]
Sent: Friday, October 28, 2011 3:01 PM
To: Nilay Vaish; Beckmann, Brad; Default
Subject: Re: Review Request: Forward invalidations from Ruby to O3 CPU

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



On October 27th, 2011, 10:35 p.m., Brad Beckmann wrote:

Thanks for the heads up on this patch.  I'm glad you found the time to dive 
into it.







I'm confused that the comment mentions a list of ports, but I don't see a 
list of ports in the code and I'm not sure how would even be used?



The two questions you pose are good ones.  Hopefully someone who understands 
the O3 LSQ can answer the first, and I would suggest creating a new directed 
test that can manipulate the enqueue latency on the mandatory queue to create 
the necessary test situations.



Also, I have a couple high-level comments right now:







- Ruby doesn't implement any particular memory model.  It just implements the 
cache coherence protocol, and more specifically invalidation based protocols.  
The protocol, in combination with the core model, results in the memory model.





- I don't think it is sufficient to just forward those probes that hit valid 
copies to the O3 model.  What about replacements of blocks that have serviced a 
speculative load?  Instead, my thought would be to forward all probes to the O3 
LSQ and think of cpu-controlled policies to filter out unecessary probes.

On October 28th, 2011, 3:32 a.m., Nilay Vaish wrote:

Hi Brad, thanks for the response.



* A list of ports has been added to RubyPort.hh, the ports are added

  to the list whenever a new M5Port is created.



* As long as the core waits for an ack from the memory system for every store

  before issuing the next one, I can understand that memory model is independent

  of how the memory system is implemented. But suppose the caches are 
multi-ported.

  Then will the core only use one of the ports for stores and wait for an ack?

  The current LSQ implementation uses as many ports as available. In this case,

  would not the memory system need to ensure the order in which the stores are

  performed?



* I think the current implementation handles blocks coherence permissions for

  which were speculatively fetched. If the cache looses permissions on this

  block, then it will forward the probe to the CPU. If the cache again receives

  a probe for this block, I don't think that the CPU will have any instruction

  using the value from that block.



* For testing, Prof. Wood suggested having some thing similar to TSOtool.

On October 28th, 2011, 9:55 a.m., Brad Beckmann wrote:

Hmm...I'm now even more confused.  I have not looked at the O3 LSQ, but it 
sounds like from your description that one particular instantiation of the LSQ 
will use N ports, not just a single port to the L1D.  So does N equal

Re: [gem5-dev] Locked RMW in Ruby

[Beckmann, Brad]

Hi Nilay,

I apologize it has taken me a few days to respond.  I need to read my gem5-dev 
email more often.

First off, I just want to be clear that we are only discussing locked prefixed 
RMW instructions, correct?  Non-locked RMW are not an issue.

In my opinion, the absolute best source to understand the x86 memory model is 
Sewell et al.  http://doi.acm.org/10.1145/1785414.1785443  In the paper, they 
explain when processors can logically execute locked prefixed instructions in a 
very clear and intuitive way.  As Steve said, locked prefixed instructions act 
as fences, but they also immediately retire to the memory system to maintain 
global ordering.  Thus the locked prefixed instruction cannot logically 
complete until all prior lds and sts from that processor have been retired to 
the memory system.  In other words, the load and store buffers must be empty.  
Furthermore, the locked prefixed instruction must immediately become visible 
when the locked prefixed instruction retires.  In other words, the store buffer 
cannot hold on to the store value after the core retires the instruction.

I think the main question here is how does the O3 ld/st queue respond to the 
serialize before, serialize after, and fence flags?  Essentially, we need to 
use the combination of flags that flushes the ld and st buffers before 
logically executing the load portion of the locked RMW, as well as bypasses the 
store buffer when executing the store portion of the locked RMW.  There are 
certainly optimizations that can be implemented to maintain that logical 
behavior, while allowing the hardware to do more parallel execution.  However, 
I would suggest not trying to implement those before getting the core 
functionality to work using existing mechanisms.

On a related note, have you thought about how you're going to propagate Ruby 
probes back to the O3 load buffer?  Assuming a snooping load queue, that is one 
core mechanism that we need to implement to support X86+O3+Ruby.  It might be 
useful for us to discuss different possible interface implementations before 
you spend too much time writing code.

Brad




 -Original Message-
 From: gem5-dev-boun...@gem5.org [mailto:gem5-dev-
 boun...@gem5.org] On Behalf Of Steve Reinhardt
 Sent: Thursday, October 27, 2011 10:09 AM
 To: gem5 Developer List
 Subject: Re: [gem5-dev] Locked RMW in Ruby
 
 Hi Nilay,
 
 I think a memory barrier may not be sufficient... we need to make sure it's
 non-speculative as well as ordered (unless we do something more
 complicated to deal with a speculative locked read that isn't followed by a
 write because it got squashed).
 
 Gabe is a better reference (the only reference?) for the details of the x86
 decoder.
 
 Steve
 
 On Thu, Oct 27, 2011 at 8:32 AM, Nilay Vaish ni...@cs.wisc.edu wrote:
 
  I am thinking of marking all the locked instructions with IsMemBarrier.
  Where do you think this flag should appear - in locked_opcodes.isa, or
  in semaphores.py? I tried adding IsMemBarrier to the instructions in
  locked_opcodes.isa, but that does not work. I changed the instruction
  format to BasicOperate, that also does not work.
 
  --
  Nilay
 
 
  On Wed, 26 Oct 2011, Gabe Black wrote:
 
   I think you guys are on the right track. There's a non speculative
  flag,
  a serialize before, and a serialize after. I'm not sure which one is
  exactly right, but some combination should be. We should be careful
  not to over do it since that might artificially hurt performance, but
  I don't *think* the lock prefix is used all that much these days so
  it shouldn't be have *too* bad an impact if it isn't perfectly correct.
 
  Gabe
 
  On 10/26/11 09:56, Nilay Vaish wrote:
 
  On Tue, 25 Oct 2011, Steve Reinhardt wrote:
 
   Good questions.  Clearly if we ever let the R part of an RMW
  instruction out
  to the cache, either we have to commit the instruction or add some
  mechanism to unlock the block.  One solution would be to mark all
  RMW instructions as serializing, which would prevent them from
  executing speculatively.
  That
  (or something like it) might be necessary to get the consistency
  model right anyway, since I believe locked accesses act as fences
  (?? is that right, Brad?).
 
  Gabe, did you have an alternate solution in mind?
 
  Steve
 
  On Tue, Oct 25, 2011 at 2:15 PM, Nilay Vaish ni...@cs.wisc.edu
 wrote:
 
   Does this mean that an x86 O3 CPU will never squash an RMW
  instruction? I
  am posting an instruction + protocol trace for obtained from O3
  and Ruby. In the first portion, you can see that the O3 CPU issues
  a locked RMW with the read part having sn = 3051 and the write
  part having sn = 3052. In the second portion, you can see that
  3051 and 3052 are squashed and the in the third portion of the
  trace, these are committed. There are several things that I am not
  able to understand. Why is the RMW squashed, since x86
  architecture has to commit the instruction? Secondly, if RMW was
  being 

Re: [gem5-dev] Ruby: Improving Simulation Speed

[Beckmann, Brad]

No, cache warmup will not use functional accesses.  An important part of cache 
warmup is to put the protocol state machines in the correct state and, as you 
know, functional accesses can't do that.  That being said,  TraceRecord might 
be able to use the RubyPort rather than the Sequencer.  What is the benefit of 
doing so?

Brad


 -Original Message-
 From: gem5-dev-boun...@gem5.org [mailto:gem5-dev-
 boun...@gem5.org] On Behalf Of Nilay Vaish
 Sent: Monday, August 29, 2011 12:33 PM
 To: gem5 Developer List
 Subject: Re: [gem5-dev] Ruby: Improving Simulation Speed
 
 Hi Brad
 
 Does it make sense that TraceRecord makes use of RubyPort instead of the
 Sequencer? I think you mentioned previously that cache warmup would
 make use of functional accesses through RubyPort.
 
 --
 Nilay
 
 
 On Wed, 24 Aug 2011, Beckmann, Brad wrote:
 
  Hi Nilay,
 
  The TraceRecord object is used by the cache warmup mechanism.  We
 need to keep it, but we probably can modify it to work with packet.
 
  Can you post your patch?  I would be interested to see the details.
 
  Brad
 
 
  -Original Message-
  From: gem5-dev-boun...@gem5.org [mailto:gem5-dev-
 boun...@gem5.org] On
  Behalf Of Nilay Vaish
  Sent: Wednesday, August 24, 2011 7:45 PM
  To: gem5-dev@gem5.org
  Subject: [gem5-dev] Ruby: Improving Simulation Speed
 
  I have a patch that makes changes to RubyPort and Sequencer.
  Essentially,
  it pushes the packet in to the Sequencer, instead of a RubyRequest as
  of now. I tested the patch with streamcluster kernel from PARSEC. On
  a run of
  3,000,000,000,000 ticks, I see an improvement of about 5.89% in total
  simulation time.
 
  There is a catch. I have removed the TraceRecord facility from Ruby
  for this. The facility currently relies on the fact that Sequencer's
  makeRequest() function takes RubyRequest as argument. But since the
  patch changes this argument to a Packet, TraceRecord will require
  some changes.
  I think the facility is not in use right now. It can be removed, or
  else it can be changed to take Packet as argument. Any suggestions?
 
  Thanks
  Nilay
  ___
  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] The O3-Ruby interface is work in progress？

[Beckmann, Brad]

As you may know, each ISA has a different memory consistency model and 
depending on the model, different information needs to be communicated between 
Ruby and the O3 LSQ.  For example, a snooping load queue typically used by TSO 
would require Ruby to communicate snoops to the LSQ.  Meanwhile, an insulated 
load queue needs to squash and restart loads that violate the consistency model.

As far as the store buffer goes, I believe there was an old thread about that.  
I seem to remember that we decided that the store buffer should live inside the 
CPU model, but I'm not sure.  That will obvious have implications on the 
O3-Ruby interface as well.

If you decide to pursue this, please use Reviewboard to keep us up-to-date with 
your progress.

Thanks,

Brad


 -Original Message-
 From: gem5-dev-boun...@gem5.org [mailto:gem5-dev-boun...@gem5.org] On
 Behalf Of huangyongbing
 Sent: Wednesday, August 24, 2011 7:32 PM
 To: gem5-dev@gem5.org
 Subject: [gem5-dev] The O3-Ruby interface is work in progress？
 
 Hi，
 
 
 
  I want to use O3-Ruby model. So I need to know how long this
 work
 will be completed. Or, what should I do in order to implement it based
 on
 current O3 CPU and Ruby codes?
 
 
 
 To my knowledge, the memory requests are sent from LSQ in O3 CPU.
 Besides
 connecting LSQ port with Ruby port, what other works are included?
 
 
 
 Hope to be replied soon. Thanks.
 
 
 
 
 
 --Yongbing Huang
 
 ___
 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] Regression Tester?

[Beckmann, Brad]

Has anyone seen a regression tester email more recent than this one below from 
last Thursday?  If not, any idea what is going with the zizzer and the 
regression tester?

Brad


 -Original Message-
 From: gem5-dev-boun...@gem5.org [mailto:gem5-dev-
 boun...@gem5.org] On Behalf Of Cron Daemon
 Sent: Thursday, August 11, 2011 12:18 AM
 To: gem5-dev@gem5.org
 Subject: [gem5-dev] Cron m5test@zizzer /z/m5/regression/do-regression
 quick
 
 scons: `build/ALPHA_SE/m5.debug' is up to date.
 scons: `build/ALPHA_SE_MOESI_hammer/m5.debug' is up to date.
 scons: `build/ALPHA_SE_MESI_CMP_directory/m5.debug' is up to date.
 scons: `build/ALPHA_SE_MOESI_CMP_directory/m5.debug' is up to date.
 scons: `build/ALPHA_SE_MOESI_CMP_token/m5.debug' is up to date.
 scons: `build/ALPHA_FS/m5.debug' is up to date.
 scons: `build/MIPS_SE/m5.debug' is up to date.
 scons: `build/POWER_SE/m5.debug' is up to date.
 scons: `build/SPARC_SE/m5.debug' is up to date.
 scons: `build/SPARC_FS/m5.debug' is up to date.
 scons: `build/X86_SE/m5.debug' is up to date.
 scons: `build/X86_FS/m5.debug' is up to date.
 scons: `build/ARM_SE/m5.debug' is up to date.
 scons: `build/ARM_FS/m5.debug' is up to date.
 scons: `build/ALPHA_SE/m5.fast' is up to date.
 scons: `build/ALPHA_SE_MOESI_hammer/m5.fast' is up to date.
 scons: `build/ALPHA_SE_MESI_CMP_directory/m5.fast' is up to date.
 scons: `build/ALPHA_SE_MOESI_CMP_directory/m5.fast' is up to date.
 scons: `build/ALPHA_SE_MOESI_CMP_token/m5.fast' is up to date.
 scons: `build/ALPHA_FS/m5.fast' is up to date.
 scons: `build/MIPS_SE/m5.fast' is up to date.
 scons: `build/POWER_SE/m5.fast' is up to date.
 scons: `build/SPARC_SE/m5.fast' is up to date.
 scons: `build/SPARC_FS/m5.fast' is up to date.
 scons: `build/X86_SE/m5.fast' is up to date.
 scons: `build/X86_FS/m5.fast' is up to date.
 scons: `build/ARM_SE/m5.fast' is up to date.
 scons: `build/ARM_FS/m5.fast' is up to date.
 * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/inorder-timing
 passed.
 * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/o3-timing
 passed.
 * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/simple-atomic
 passed.
 * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/simple-timing
 passed.
 * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/simple-timing-
 ruby passed.
 * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/tru64/o3-timing
 passed.
 * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/tru64/simple-atomic
 passed.
 * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/tru64/simple-timing
 passed.
 * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/tru64/simple-timing-
 ruby passed.
 * build/ALPHA_SE/tests/opt/quick/01.hello-2T-smt/alpha/linux/o3-
 timing passed.
 * build/ALPHA_SE/tests/opt/quick/20.eio-short/alpha/eio/simple-
 atomic passed.
 * build/ALPHA_SE/tests/opt/quick/20.eio-short/alpha/eio/simple-
 timing passed.
 * build/ALPHA_SE/tests/opt/quick/30.eio-mp/alpha/eio/simple-
 atomic-mp passed.
 * build/ALPHA_SE/tests/opt/quick/30.eio-mp/alpha/eio/simple-timing-
 mp passed.
 * build/ALPHA_SE/tests/opt/quick/50.memtest/alpha/linux/memtest
 passed.
 * build/ALPHA_SE/tests/opt/quick/50.memtest/alpha/linux/memtest-
 ruby passed.
 * build/ALPHA_SE/tests/opt/quick/60.rubytest/alpha/linux/rubytest-
 ruby passed.
 *
 build/ALPHA_SE_MOESI_hammer/tests/opt/quick/00.hello/alpha/linux/sim
 ple-timing-ruby-MOESI_hammer passed.
 *
 build/ALPHA_SE_MOESI_hammer/tests/opt/quick/00.hello/alpha/tru64/sim
 ple-timing-ruby-MOESI_hammer passed.
 *
 build/ALPHA_SE_MOESI_hammer/tests/opt/quick/50.memtest/alpha/linux/
 memtest-ruby-MOESI_hammer passed.
 *
 build/ALPHA_SE_MOESI_hammer/tests/opt/quick/60.rubytest/alpha/linux/r
 ubytest-ruby-MOESI_hammer passed.
 *
 build/ALPHA_SE_MESI_CMP_directory/tests/opt/quick/00.hello/alpha/linux
 /simple-timing-ruby-MESI_CMP_directory passed.
 *
 build/ALPHA_SE_MESI_CMP_directory/tests/opt/quick/50.memtest/alpha/li
 nux/memtest-ruby-MESI_CMP_directory passed.
 *
 build/ALPHA_SE_MESI_CMP_directory/tests/opt/quick/00.hello/alpha/tru64
 /simple-timing-ruby-MESI_CMP_directory passed.
 *
 build/ALPHA_SE_MESI_CMP_directory/tests/opt/quick/60.rubytest/alpha/li
 nux/rubytest-ruby-MESI_CMP_directory passed.
 *
 build/ALPHA_SE_MOESI_CMP_directory/tests/opt/quick/00.hello/alpha/tru
 64/simple-timing-ruby-MOESI_CMP_directory passed.
 *
 build/ALPHA_SE_MOESI_CMP_directory/tests/opt/quick/00.hello/alpha/linu
 x/simple-timing-ruby-MOESI_CMP_directory passed.
 *
 build/ALPHA_SE_MOESI_CMP_directory/tests/opt/quick/50.memtest/alpha
 /linux/memtest-ruby-MOESI_CMP_directory passed.
 *
 build/ALPHA_SE_MOESI_CMP_directory/tests/opt/quick/60.rubytest/alpha/
 linux/rubytest-ruby-MOESI_CMP_directory passed.
 *
 build/ALPHA_SE_MOESI_CMP_token/tests/opt/quick/00.hello/alpha/linux/s
 imple-timing-ruby-MOESI_CMP_token passed.
 *
 

Re: [gem5-dev] Power models

[Beckmann, Brad]

Hi Digant,

Yes, Joel Hestness, with some assistance from others, is currently working on 
integrating McPAT into gem5.  Most of the integration is complete and Joel is 
exploring options on how to verify his work.

Joel, can you comment further?

Thanks,

Brad


 -Original Message-
 From: gem5-dev-boun...@gem5.org [mailto:gem5-dev-
 boun...@gem5.org] On Behalf Of Digant
 Sent: Friday, August 05, 2011 10:24 AM
 To: gem5-dev@gem5.org
 Subject: [gem5-dev] Power models
 
 Hi all,
 anybody working on power models ?
 
 Regards,
 Digant Desai.
 ___
 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: GARNET: adding a fault model for resilient on-chip network research.

[Beckmann, Brad]

Yeah, after I sent that last email I thought that it might be related to the 
fact that I did a clean build, not updating to the latest repo.  Over the past 
3-4 months I've noticed several random swig errors that are fixed by trying a 
clean build.  I hope this is just another one of those situations.

Brad


From: Steve Reinhardt [mailto:ste...@gmail.com]
Sent: Wednesday, July 27, 2011 5:35 PM
To: Konstantinos Aisopos
Cc: Beckmann, Brad; gem5 Developer List
Subject: Re: [gem5-dev] Review Request: GARNET: adding a fault model for 
resilient on-chip network research.

Can you try a clean build (rm -rf build)?  When Brad said that it broke for him 
in an older version, but worked at the head, I tried to track it down and 
couldn't reliably reproduce it in any version up to over a month old.  But I 
did see it once, which makes me wonder if it's just some stale build glitch.

Steve
On Wed, Jul 27, 2011 at 4:49 PM, Konstantinos Aisopos 
kaisopos.g...@gmail.commailto:kaisopos.g...@gmail.com wrote:
hi Steve and Brad,

I updated to the latest version of the repo and the problem persists.

Specifically, I did the same experiment Steve suggested (added the
same 2 lines in src/sim/System.py and src/sim/system.cc) and I got the
same segmentation fault I get when I add an integer vector into my
fault model python file:


kaisopos@hermes1:~/GEM5_Fault_Model/gem5$ build/ALPHA_SE/gem5.debug
configs/example/se.py
gem5 Simulator System.  http://gem5.org
gem5 is copyrighted software; use the --copyright option for details.
gem5 compiled Jul 27 2011 19:23:03
gem5 started Jul 27 2011 19:24:15
gem5 executing on hermes1
command line: build/ALPHA_SE/gem5.debug configs/example/se.py
Global frequency set at 1 ticks per second
Traceback (most recent call last):
 File string, line 1, in module
 File /data/lsp/kaisopos/GEM5_Fault_Model/gem5/src/python/m5/main.py,
line 356, in main
   exec filecode in scope
 File configs/example/se.py, line 199, in module
   Simulation.run(options, root, system, FutureClass)
 File /data/lsp/kaisopos/GEM5_Fault_Model/gem5/configs/common/Simulation.py,
line 235, in run
   m5.instantiate(checkpoint_dir)
 File /data/lsp/kaisopos/GEM5_Fault_Model/gem5/src/python/m5/simulate.py,
line 78, in instantiate
   for obj in root.descendants(): obj.createCCObject()
 File /data/lsp/kaisopos/GEM5_Fault_Model/gem5/src/python/m5/SimObject.py,
line 881, in createCCObject
   self.getCCParams()
 File /data/lsp/kaisopos/GEM5_Fault_Model/gem5/src/python/m5/SimObject.py,
line 840, in getCCParams
   assert not len(vec)
TypeError: object of type 'PySwigObject' has no len()


I am using the latest code (I did hg pull -u right before compiling)
I am using Python 2.5.2 and SWIG 1.3.36
If the same code worked for both of you, the problem has to be either
Python or SWIG, right?
or is there any other possible explanation? any other thoughts?

thanks all of you for helping out,
-Kostas

On Wed, Jul 27, 2011 at 4:38 PM, Steve Reinhardt 
ste...@gmail.commailto:ste...@gmail.com wrote:
 Weird... I don't see any changes in the last three weeks that would have
 affected that.
 Thanks for figuring that out though, Brad.
 Steve

 On Wed, Jul 27, 2011 at 1:27 PM, Beckmann, Brad 
 brad.beckm...@amd.commailto:brad.beckm...@amd.com
 wrote:

 Hi Konstantinos,

 FYI, I was able to reproduce your error when I used a 3-week old version
 of the repo.  However, I updated to the latest version of the repo and the
 problem appears fixed.  I can now reproduce the correct behavior that Steve
 observed.

 Brad


  -Original Message-
  From: gem5-dev-boun...@gem5.orgmailto:gem5-dev-boun...@gem5.org 
  [mailto:gem5-dev-mailto:gem5-dev-
  boun...@gem5.orgmailto:boun...@gem5.org] On Behalf Of Steve Reinhardt
  Sent: Wednesday, July 27, 2011 8:25 AM
  To: Konstantinos Aisopos; Default
  Subject: Re: [gem5-dev] Review Request: GARNET: adding a fault model for
  resilient on-chip network research.
 
  (Getting this off of reviewboard so it's easier to reply...)
 
  Hi Konstantinos,
 
  I just made this change at the head of the tree:
 
  diff --git a/src/sim/System.py b/src/sim/System.py
  --- a/src/sim/System.py
  +++ b/src/sim/System.py
  @@ -44,6 +44,8 @@
   def swig_objdecls(cls, code):
   code('%include python/swig/system.i')
 
  +test = VectorParam.Int([1, 2, 3], )
  +
   physmem = Param.PhysicalMemory(Physical Memory)
   mem_mode = Param.MemoryMode('atomic', The mode the memory
  system is
  in)
   memories = VectorParam.PhysicalMemory(Self.all, All memories is
  the
  system)
  diff --git a/src/sim/system.cc b/src/sim/system.cc
  --- a/src/sim/system.cc
  +++ b/src/sim/system.cc
  @@ -83,6 +83,8 @@
   // add self to global system list
   systemList.push_back(this);
 
  +cprintf(%s.test: len %d, %d\n, name(), p-test.size(),
  + p-test[0]);
  +
   /** Keep track of all memories we can execute code out of
* in our system

Re: [gem5-dev] se.py

[Beckmann, Brad]

I'm fine with how things are now, but if we do change things up, I would prefer 
removing the RUBY flag and no longer making the MI_example protocol the 
default.  Instead, if a protocol is specified, scons builds Ruby, otherwise 
scons does not build Ruby.  In my opinion, the protocol is fundamental to Ruby 
and I'm not sure how we could use other aspects of it without compiling in a 
protocol (ex. NetworkTest).

Brad


 -Original Message-
 From: gem5-dev-boun...@gem5.org [mailto:gem5-dev-boun...@gem5.org] On
 Behalf Of Nilay Vaish
 Sent: Sunday, July 10, 2011 9:20 AM
 To: gem5 Developer List
 Subject: Re: [gem5-dev] se.py
 
 On Sat, 9 Jul 2011, nathan binkert wrote:
 
  It might appear as if coherence protocols are the only thing that is
 there
  to ruby. If some time down the line, protocols were to become
 optional
  meaning you could use some part of ruby with out using the coherence
  protocols themselves, would you still want to go on with the check
 on the
  variable PROTOCOL? The variable PROTOCOL should only be used for
 things
  related to protocols themselves. Why would you want to use it to
 enable /
  disable options for, say, topology?
  In the long run, we want to get rid of as many compile time options
 as
  possible.  If there are useful parts of ruby that are not part of a
  protocol, then we should always just compile them in.
 
 
 Though I was thinking about se.py all the time, from Gabe's and Nate's
 response, it seems that my comment was interpreted for setting
 compilation
 options. I would say even for compilation, I prefer using RUBY rather
 than
 PROTOCOL. It might be so because that's what I have been doing all the
 time. I almost never use PROTOCOL.
 
 I am fine with elimination of RUBY as a compile time option. But I
 still
 prefer retaining RUBY as a variable and using it to check whether or
 not
 to build certain components, like we do right now. This variable would
 be
 set depending on whether PROTOCOL is supplied at compile time or not.
 As
 Nate suggested in a previous email, --ruby is provided as an option
 only
 if PROTOCOL was present in the build env.
 
 --
 Nilay
 ___
 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] Cron m5test@zizzer /z/m5/regression/do-regression quick

[Beckmann, Brad]

Anyone know what happened to the regression tester last night?  I don't have 
access to zizzer to check myself.

Thanks,

Brad


 -Original Message-
 From: gem5-dev-boun...@gem5.org [mailto:gem5-dev-
 boun...@gem5.org] On Behalf Of Cron Daemon
 Sent: Friday, July 01, 2011 12:00 AM
 To: gem5-dev@gem5.org
 Subject: [gem5-dev] Cron m5test@zizzer /z/m5/regression/do-regression
 quick
 
 
 See /z/m5/regression/regress-2011-07-01-03:00:01 for details.
 
 ___
 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] [m5-dev] Ruby Cache Warmup

[Beckmann, Brad]

Hi Somayeh,

As long as you don't set the cache warmup flag in the ruby event queue shim 
layer, the ruby event queue calls will schedule events on the main event queue. 
 All you have to do is remove that enableCacheWarmup call in the 
Tracer::playbackTrace function.

Brad


 -Original Message-
 From: soma...@cs.wisc.edu [mailto:soma...@cs.wisc.edu]
 Sent: Sunday, June 26, 2011 1:42 PM
 To: Beckmann, Brad; Steve Reinhardt
 Cc: gem5 Developer List
 Subject: Re: [gem5-dev] [m5-dev] Ruby Cache Warmup
 
 Hi,
 
 Currently, for each trace record we create a Ruby request by calling
 Sequencer::makeRequest. Later, in
 RubyEventQueue::scheduleEventAbsolute
 they will be scheduled (pushed back) on the prio_heap.
 
 To implement the new cache warmup, I can similarly call
 Sequencer::makeRequest, but then where is the best place to schedule
 these events on mainEventQueue instead of RubyEventQueue/prio_heap?
 
 
 Thanks,
 Somayeh
 
  On Fri, Jun 24, 2011 at 4:01 PM, soma...@cs.wisc.edu wrote:
 
  Hi,
 
  I like Steve's idea. The basic idea is similar to the current
  implementation (i.e., having a second event queue) but without
  hijacking Ruby APIs.
 
  I have a question regarding Nate's and Steve's discussion on the head
  pointer. Do I need to have a swap function implemented or I can make
  the pointer public and change it (e.g., set it NULL)?
 
 
  We definitely don't want to just make the pointer public... something
  like a swap method is much preferred.
 
  Steve
 
 
 
 
  Thanks,
  Somayeh
 
   On Fri, Jun 24, 2011 at 11:52 AM, nathan binkert n...@binkert.org
  wrote:
  
Your latest suggestion is very similar to how the current patch
  works.
The only difference is that the Ruby event queue shim layer does
   a logical pointer swap and not a physical pointer swap within the
   main gem5
  event
   queue itself.  I'm somewhat leery of making the event queue head
  pointer
   public, but if you're ok with it, then I'll go along with it.  It
   certainly will be less work for Somayeh...no need to worry about
   events
  scheduling
   past T-1 ticks, etc.
  
   Let's definitely not make the head pointer public.  I think that
   the right thing to do is create a swap() function (for those of
   you that don't know, swap is a very common concept in the STL).
   Then we can create a temporary queue, swap it with the main queue,
   run
  everything,
   and when it is done, swap it back.  The swap function would be
  public,
   but nothing else would be.
  
  
   Agreed, I was about to say something similar but you beat me to it.
  This
   could also be done by making the copy and assignment operators
   public (swap the state out by copying it to a new object, restore
   by assigning the state back).
  
   Of course, we really just want to swap the head pointer and not
   necessarily the name, so maybe a swap() on the head pointer would
   be better, but I don't know that it's worth quibbling about whether
   that happens or not.
  
  
   This seems to me to be the safest way to ensure that everything
   works as expected.  I'd also like to see _curTick moved into the
   eventQueue itself, and the global curTick() function should call
   mainEventQueue.curTick().  (Is this what you've done for your
  multiple
   event queue patch steve?)
  
  
   No, my patch just puts _curTick in TLS using __thread.  It's been a
  while,
   but I'm pretty sure there are places where curTick() gets called
   where
  you
   don't have easy access to which queue you're on (e.g., inside of a
  DPRINTF
   that's not in a method associated with an EventManager object) so
   you really want a TLS pointer to tell you where you're at.  You
   could put curTick
  in
   the event queue and then have an EventQueue* in TLS, but that seems
  like
   an
   unnecessary indirection, unless it turns out that we need that
   queue pointer to be in TLS also (which may happen, but I'm not
   convinced that it
  will).
  
   It's an interesting debate to have, but I'd prefer to see it
   decoupled from Ruby warm-up so that Somayeh doesn't get held up on
   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] [m5-dev] Ruby Cache Warmup

[Beckmann, Brad]

Thanks Steve.

Your latest suggestion is very similar to how the current patch works.  The 
only difference is that the Ruby event queue shim layer does a logical pointer 
swap and not a physical pointer swap within the main gem5 event queue itself.  
I'm somewhat leery of making the event queue head pointer public, but if you're 
ok with it, then I'll go along with it.  It certainly will be less work for 
Somayeh...no need to worry about events scheduling past T-1 ticks, etc.

Does that all make sense to you Somayeh?

Brad


From: Steve Reinhardt [mailto:ste...@gmail.com]
Sent: Friday, June 24, 2011 10:07 AM
To: Beckmann, Brad
Cc: soma...@cs.wisc.edu; gem5 Developer List
Subject: Re: [gem5-dev] [m5-dev] Ruby Cache Warmup


On Fri, Jun 24, 2011 at 9:16 AM, Beckmann, Brad 
brad.beckm...@amd.commailto:brad.beckm...@amd.com wrote:
Hi Somayeh,

Thanks for the questions.  We definitely want to make sure we're all on the 
same page before we start coding.  My answers are below:

 why do you think we need to ensure that there is no event scheduled for
 ticks T or more? We only need to make sure all Ruby cache warmup events
 are done before T regardless of what have been scheduled for after that.
Sorry for the confusion.  You are right that other events may be scheduled for 
ticks T or more.  In particular, during the unserialization phase, I suspect 
several events will be placed on the event queue for tick T or more.  There may 
even be other events put on the event queue for tick T or more during other 
SimObjects' startup routines.  The key is that we should make sure during the 
cache warmup phase (within Topology::startup) that all events scheduled are for 
ticks T-1 or less.

 What if T is not large enough to finish cache warmup? do we need to stop
 other scheduled events?!
We need to call fatal and return a description that T is not large enough 
(include the value of T in the error message).

I agree with what Brad is saying, but just to be crystal clear on the 
mechanism: I believe that resetting curTick to 0 and calling simulate(T-1) 
should be adequate, as it will force us out of the simulation loop at T-1 
whether or not the Ruby transaction is complete.  If we hit T-1 and the 
transaction is not complete, then we can call fatal.  As long as there are no 
Ruby components that schedule events past the completion of a transaction, this 
should be safe.  If there is a chance that additional events could be scheduled 
(e.g., replacement writebacks?) then we would need to have a way to check that 
Ruby is completely idle at T-1.

I think it would be awkward to have a mode where we test every event that's 
scheduled to make sure it doesn't have a timestamp that goes past T.  If we 
decide that something like that is really necessary, then I might consider 
switching to Nate's idea of just using a separate event queue.  Another 
possibility that might be a little easier to code than having to walk all of 
the Ruby objects and switch their event queue pointer would be to temporarily 
move the existing events out of the way, then restore them at the end.  Hmm, 
now that I said that, that sounds pretty appealing... it's easy to do since the 
event queue is basically a linked list (just save the head pointer somewhere 
and replace it with NULL).  How's this for another option (still called from 
someone's startup() method):

   1. Save the (already restored) curTick() value (call this T).
   2. Save the event queue head pointer value, replace with NULL (will need to 
add an EventQueue method for this, since head is private).
   3. Set curTick to 0 (optional, but might be useful even if just to make it 
obvious that this isn't the real simulation)
   4. Schedule and event to inject the first transaction at time 0 (or T if we 
didn't reset curTick, or maybe just inject it directly?)
   5. Call simulate()
5.1. In the callback function as each transaction completes, inject the 
next transaction.
5.2. When there are no more transactions, either call exitSimLoop() 
directly or just wait for the MAXINT event that simulate() schedules to kick us 
out of the loop.  (I think the latter is safer, since it guarantees that any 
trailing events like writebacks will complete.)
   6. Restore event queue head pointer.
   7. Re-restore curTick to T.

Thoughts?

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