[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
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
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
+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
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
o 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 i
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
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
, 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
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
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
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
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.
>>>> 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
>>>>
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
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
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
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
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
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
: 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
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
@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
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
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
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
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,
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
. 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
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
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
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
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
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
, 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
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
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) {
+
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
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
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
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
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
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
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
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
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
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
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
: 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
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
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
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
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
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
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
/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
, 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
. 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
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
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
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
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
. 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
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
: 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
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.
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,
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
-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
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
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
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
-
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
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
: 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
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
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
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
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
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:
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
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
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
[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
, 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
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
-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
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
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
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
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
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
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,
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
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:
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
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
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:
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
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
100 matches
Mail list logo
