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, "
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
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 ex
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 pu
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
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. Ac
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
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 [mailto:gem5-dev-boun
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 modif
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 co
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
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,
>
> Quic
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
u 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
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
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 th
Andreas, we record the "owner" of the cache block in the trace. This
methodology simplifies the configuration dependencies on the checkpoint and has
worked well for Ruby for 15 years. There is actually an old paper from MIT
that describes a more complete way of recording the owner of a cache b
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
[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
21 matches
Mail list logo
