[gem5-dev] Simulating a new system configuration

[rohith mathew]

Hi,

I am trying to implement a HTM(Hardware Transactional Memory) in Gem5 with
x86. For that I want to configure a system with 4 cores, each having 2
levels of private caches and a third level of shared cache. can anyone help
me out with this, because I am really new to this Gem5.

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

Re: [gem5-dev] HTM implementation

[rohith mathew]

Hi Blake,

Thanks for the support. The problem is that I am really new to this
architecture area and so to Gem5. So I am hoping to have your support in
future also.

regards,
Rohith

On Wed, Nov 4, 2015 at 10:29 PM, Geoffrey Blake  wrote:

> Hi Rohith,
>
> It is possible to add the code you are suggesting in your message.  You
> will also have to modify the simulator atomic CPU models to do the proper
> things to not leak memory accesses,  and perform rollback of the
> transactional state in case of conflicts in addition to adding your
> database based conflict detection and versioning.  If you intend to extend
> this to timing mode and the caches you will also have to dig into the cache
> coherence and cache models as well unless faking it via the database is
> sufficient for your needs.
>
> In the past I had a version of gem5 that had LogTM support for Alpha, and
> it appears to still exist at http://www.eecs.umich.edu/~blakeg/ at the
> bottom of the page if you want to look at a potential starting point.
>
> Thanks,
> Geoff Blake
>
> On Wed, Nov 4, 2015 at 6:00 AM, rohith mathew 
> wrote:
>
> > Hi all,
> >
> > I'm trying to implement a syatem with a Hardware Transactional
> Memory(HTM)
> > in gem5 with x86. I just want to know whether it is possible to have a
> > database in the main memory for the operation of HTM. If possible can
> > anyone give me some suggestions to do that.
> >
> > Thanks in advance.
> >
> > regards,
> > Rohith
> > ___
> > 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 3172: mem: Use the packet delays and do not just zero them out

[Steve Reinhardt]

> On Nov. 3, 2015, 9:37 p.m., Steve Reinhardt wrote:
> > src/dev/io_device.cc, line 60
> > 
> >
> > out of scope for now, but just a thought: arguably this zeroing of the 
> > delay fields should probably take place in Packet::makeResponse()
> 
> Andreas Hansson wrote:
> No. It relly should never implicitly be zeroed.
> 
> If we re-use the packet without paying for the latency on the request 
> path, we rely on it being paid for on the response path.

ok, makes sense


> On Nov. 3, 2015, 9:37 p.m., Steve Reinhardt wrote:
> > src/mem/simple_mem.cc, line 164
> > 
> >
> > this code looks awfully familiar :).  is there a way to use PacketQueue 
> > here to avoid the redundancy?
> 
> Andreas Hansson wrote:
> It was historically using the packet queue. I The main reason for moving 
> away from it is to be able to bound the number of outstanding responses. Till 
> now that hasn't happened, but I am inclined to not use the SimpleTimingPort 
> here.

ok.  would be nice to factor out the common code somehow, but it's a small 
enough thing that the redundancy is tolerable I suppose.


> On Nov. 3, 2015, 9:37 p.m., Steve Reinhardt wrote:
> > src/dev/io_device.cc, line 59
> > 
> >
> > minor, but 'additional_latency' is rather nondescript. maybe 
> > 'transmission_delay' or 'receive_delay' or 'receive_latency' or something 
> > like thet?
> 
> Andreas Hansson wrote:
> It is headerDelay (pipeline delay) and payloadDelay (de-serialisation 
> delay). I am happy to change, but I don't think there is a short and snappy 
> word describing it.

I see you changed it anyway, thanks.  'receive_delay' may not be perfectly 
descriptive, but it's an improvement I think.


- Steve


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


On Nov. 4, 2015, 1:34 a.m., Andreas Hansson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3172/
> ---
> 
> (Updated Nov. 4, 2015, 1:34 a.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11191:d5063101794c
> ---
> mem: Use the packet delays and do not just zero them out
> 
> This patch updates the I/O devices, bridge and simple memory to take
> the packet header and payload delay into account in their latency
> calculations. In all cases we add the header delay, i.e. the
> accumulated pipeline delay of any crossbars, and the payload delay
> needed for deserialisation of any payload.
> 
> Due to the additional unknown latency contribution, the packet queue
> of the simple memory is changed to use insertion sorting based on the
> time stamp. Moreover, since the memory hands out exclusive (non
> shared) responses, we also need to ensure ordering for reads to the
> same address.
> 
> 
> Diffs
> -
> 
>   src/dev/io_device.cc 2d1d51615e0e 
>   src/dev/pcidev.cc 2d1d51615e0e 
>   src/mem/bridge.cc 2d1d51615e0e 
>   src/mem/simple_mem.hh 2d1d51615e0e 
>   src/mem/simple_mem.cc 2d1d51615e0e 
> 
> Diff: http://reviews.gem5.org/r/3172/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Andreas Hansson
> 
>

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

Re: [gem5-dev] Review Request 3172: mem: Use the packet delays and do not just zero them out

[Steve Reinhardt]

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

Ship it!


Ship It!

- Steve Reinhardt


On Nov. 4, 2015, 1:34 a.m., Andreas Hansson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3172/
> ---
> 
> (Updated Nov. 4, 2015, 1:34 a.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11191:d5063101794c
> ---
> mem: Use the packet delays and do not just zero them out
> 
> This patch updates the I/O devices, bridge and simple memory to take
> the packet header and payload delay into account in their latency
> calculations. In all cases we add the header delay, i.e. the
> accumulated pipeline delay of any crossbars, and the payload delay
> needed for deserialisation of any payload.
> 
> Due to the additional unknown latency contribution, the packet queue
> of the simple memory is changed to use insertion sorting based on the
> time stamp. Moreover, since the memory hands out exclusive (non
> shared) responses, we also need to ensure ordering for reads to the
> same address.
> 
> 
> Diffs
> -
> 
>   src/dev/io_device.cc 2d1d51615e0e 
>   src/dev/pcidev.cc 2d1d51615e0e 
>   src/mem/bridge.cc 2d1d51615e0e 
>   src/mem/simple_mem.hh 2d1d51615e0e 
>   src/mem/simple_mem.cc 2d1d51615e0e 
> 
> Diff: http://reviews.gem5.org/r/3172/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Andreas Hansson
> 
>

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

Re: [gem5-dev] Review Request 3158: mem: Add an option to perform clean writebacks from caches

[Steve Reinhardt]

> On Nov. 3, 2015, 11:11 p.m., Steve Reinhardt wrote:
> > src/mem/packet.hh, line 148
> > 
> >
> > maybe instead of IsWriteback, we should add IsEviction, and set that on 
> > all three commands
> > 
> > then we could:
> >  - replace evictingBlock() with isEviction()
> >  - define isWriteback() as isEviction() && hasData()
> >  - create an isCleanEviction() that is isEviction() && 
> > !needsExclusive() (assuming we get rid of NeedsExclusive on 
> > WritebackClean), and use that to replace all the "== CleanEvict || == 
> > WritebackClean" expressions
> 
> Andreas Hansson wrote:
> I would prefer the addition of "IsEviction" to be in a separate follow-on 
> patch.

Any reason?  Since you're just introducing IsWriteback in this patch, if we're 
going to replace it with IsEviction, seems preferable to me not to introduce 
IsWriteback in the first place.

It would be nice to have a Packet::isCleanEviction() method regardless, I think.


- Steve


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


On Nov. 4, 2015, 9:53 a.m., Andreas Hansson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3158/
> ---
> 
> (Updated Nov. 4, 2015, 9:53 a.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11198:7445f17936f5
> ---
> mem: Add an option to perform clean writebacks from caches
> 
> This patch adds the necessary commands and cache functionality to
> allow clean writebacks. This functionality is crucial, especially when
> having exclusive (victim) caches. For example, if read-only L1
> instruction caches are not sending clean writebacks, there will never
> be any spills from the L1 to the L2. At the moment the cache model
> defaults to not sending clean writebacks, and this should possibly be
> re-evaluated.
> 
> The implementation of clean writebacks relies on a new packet command
> WritebackClean, which acts much like a Writeback (renamed
> WritebackDirty), and also much like a CleanEvict. On eviction of a
> clean block the cache either sends a clean evict, or a clean
> writeback, and if any copies are still cached upstream the clean
> evict/writeback is dropped. Similarly, if a clean evict/writeback
> reaches a cache where there are outstanding MSHRs for the block, the
> packet is dropped. In the typical case though, the clean writeback
> allocates a block in the downstream cache, and marks it writable if
> the evicted block was writable.
> 
> The patch changes the O3_ARM_v7a L1 cache configuration and the
> default L1 caches in config/common/Caches.py
> 
> 
> Diffs
> -
> 
>   src/mem/coherent_xbar.cc 2d1d51615e0e 
>   src/mem/packet.hh 2d1d51615e0e 
>   src/mem/packet.cc 2d1d51615e0e 
>   src/mem/snoop_filter.cc 2d1d51615e0e 
>   src/mem/cache/Cache.py 2d1d51615e0e 
>   src/mem/cache/base.hh 2d1d51615e0e 
>   src/mem/cache/cache.hh 2d1d51615e0e 
>   src/mem/cache/cache.cc 2d1d51615e0e 
>   configs/common/Caches.py 2d1d51615e0e 
>   configs/common/O3_ARM_v7a.py 2d1d51615e0e 
>   src/mem/abstract_mem.cc 2d1d51615e0e 
> 
> Diff: http://reviews.gem5.org/r/3158/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Andreas Hansson
> 
>

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

Re: [gem5-dev] Review Request 3156: mem: Add cache clusivity

[Steve Reinhardt]

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



src/mem/cache/base.hh (line 244)


so I assume this is just to give us a definition on BaseCache that we can 
use above?  Is there any good reason we still have the BaseCache/Cache split 
now that the templating is gone?

Alternatively, we could move allocateMissBuffer(), allocateWriteBuffer(), 
and this function down into Cache.  The only reason they were up here in the 
first place was to factor out some common non-templated code, but now there's 
really no reason for them to be up in BaseCache at all IMO.


- Steve Reinhardt


On Nov. 4, 2015, 4:52 a.m., Andreas Hansson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3156/
> ---
> 
> (Updated Nov. 4, 2015, 4:52 a.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11195:8bf51d20200d
> ---
> mem: Add cache clusivity
> 
> This patch adds a parameter to control the cache clusivity, that is if
> the cache is mostly inclusive or exclusive. At the moment there is no
> intention to support strict policies, and thus the options are: 1)
> mostly inclusive, or 2) mostly exclusive.
> 
> The choice of policy guides the behaviuor on a cache fill, and a new
> helper function, allocOnFill, is created to encapsulate the decision
> making process. For the timing mode, the decision is annotated on the
> MSHR on sending out the downstream packet, and in atomic we directly
> pass the decision to handleFill. We (ab)use the tempBlock in cases
> where we are not allocating on fill, leaving the rest of the cache
> unaffected. Simple and effective.
> 
> This patch also makes it more explicit that multiple caches are
> allowed to consider a block writable (this is the case
> also before this patch). That is, for a mostly inclusive cache,
> multiple caches upstream may also consider the block exclusive. The
> caches considering the block writable/exclusive all appear along the
> same path to memory, and from a coherency protocol point of view it
> works due to the fact that we always snoop upwards in zero time before
> querying any downstream cache.
> 
> Note that this patch does not introduce clean writebacks. Thus, for
> clean lines we are essentially removing a cache level if it is made
> mostly exclusive. For example, lines from the read-only L1 instruction
> cache or table-walker cache are always clean, and simply get dropped
> rather than being passed to the L2. If the L2 is mostly exclusive and
> does not allocate on fill it will thus never hold the line. A follow
> on patch adds the clean writebacks.
> 
> The patch changes the L2 of the O3_ARM_v7a CPU configuration to be
> mostly exclusive (and stats are affected accordingly).
> 
> 
> Diffs
> -
> 
>   configs/common/O3_ARM_v7a.py 2d1d51615e0e 
>   src/mem/cache/Cache.py 2d1d51615e0e 
>   src/mem/cache/base.hh 2d1d51615e0e 
>   src/mem/cache/cache.hh 2d1d51615e0e 
>   src/mem/cache/cache.cc 2d1d51615e0e 
>   src/mem/cache/mshr.hh 2d1d51615e0e 
>   src/mem/cache/mshr.cc 2d1d51615e0e 
>   src/mem/cache/mshr_queue.hh 2d1d51615e0e 
>   src/mem/cache/mshr_queue.cc 2d1d51615e0e 
> 
> Diff: http://reviews.gem5.org/r/3156/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Andreas Hansson
> 
>

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

Re: [gem5-dev] Review Request 3156: mem: Add cache clusivity

[Steve Reinhardt]

> On Nov. 3, 2015, 10:41 p.m., Steve Reinhardt wrote:
> > src/mem/cache/cache.hh, line 295
> > 
> >
> > doesn't ReadReq include most reads?  seems like mostly_excl would not 
> > be mostly exclusive then.
> 
> Andreas Hansson wrote:
> ReadReq is never issues by a cache, this by checking for it we now that 
> it came from a non-cache (CPU, table walker, device etc). This comes back to 
> my previous point about having a "FromCache" attribute.

Right, I forgot about the ReadCleanReq/ReadSharedReq change.


> On Nov. 3, 2015, 10:41 p.m., Steve Reinhardt wrote:
> > src/mem/cache/cache.cc, line 1097
> > 
> >
> > I'm confused as to why the writeback of tempBlock is treated 
> > differently from all the other writebacks.
> 
> Andreas Hansson wrote:
> I am not sure I understand your question. Is it "why don't we just stick 
> it on the list of writebacks"?

yes, exactly


> On Nov. 3, 2015, 10:41 p.m., Steve Reinhardt wrote:
> > src/mem/cache/cache.cc, line 2352
> > 
> >
> > should be '||='?
> > 
> > Also, it seems a little odd that we wait until we're issuing the 
> > request to look at the target packets and decide whether to allocate or 
> > not.  Couldn't we look at the commands as we add the targets to the MSHR?
> 
> Andreas Hansson wrote:
> Is there such a thing?
> 
> I will look into the possibility of moving it. I'm not terribly happy 
> with how it is done currently.

ah, true, in the back of my head I guess I assumed the C op= assignments were 
complete wrt the binary operators.  not the case.  guess I'm getting rusty :).


> On Nov. 3, 2015, 10:41 p.m., Steve Reinhardt wrote:
> > src/mem/cache/cache.hh, line 294
> > 
> >
> > why not MemCmd::Writeback?
> 
> Andreas Hansson wrote:
> We never fill writebacks. The allocation of writebacks from above is thus 
> never querying this function.

ok, I see.  so this function is not a complete definition of all the operations 
that will cause an allocation in a mostly_excl cache, as one might naively 
suspect...


> On Nov. 3, 2015, 10:41 p.m., Steve Reinhardt wrote:
> > src/mem/cache/cache.hh, line 291
> > 
> >
> > it would be much more in the style of Packet to add an AlwaysAlloc 
> > value to Packet::Attribute (and a corresponding alwaysAlloc() method to 
> > test it), then add that attribute to the appropriate commands in 
> > MemCmd::commandInfo[] in packet.cc.  Then this test would just be
> > 
> >   clusivity == Enums::mostly_incl || pkt->alwaysAlloc()
> > 
> > That would also make it clear that the decision needs to be made for 
> > each command type; with lists like this it's always easy to think you have 
> > it covered but leave one out.
> 
> Andreas Hansson wrote:
> I am tempted to rather make the flag "FromCache" or similar to also be 
> useful for the tests in the cache that surrounds how we response upwards. I 
> would prefer to shift this to a follow-on patch to not make this more complex 
> than it already is.

just a different kind of complexity, IMO, but since the change would be hidden 
inside this function, it seems reasonably separable.  I like 'FromCache' better 
as well.


- Steve


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


On Nov. 4, 2015, 4:52 a.m., Andreas Hansson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3156/
> ---
> 
> (Updated Nov. 4, 2015, 4:52 a.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11195:8bf51d20200d
> ---
> mem: Add cache clusivity
> 
> This patch adds a parameter to control the cache clusivity, that is if
> the cache is mostly inclusive or exclusive. At the moment there is no
> intention to support strict policies, and thus the options are: 1)
> mostly inclusive, or 2) mostly exclusive.
> 
> The choice of policy guides the behaviuor on a cache fill, and a new
> helper function, allocOnFill, is created to encapsulate the decision
> making process. For the timing mode, the decision is annotated on the
> MSHR on sending out the downstream packet, and in atomic we directly
> pass the decision to handleFill. We (ab)use the tempBlock in cases
> where we are not allocating on fill, leaving the rest of the cache
> unaffected. Simple and effective.
> 
> This patch also makes it more 

[gem5-dev] changeset in gem5: configs: fix bug introduced due to 276ad9121192

[Nilay Vaish]

changeset 854e61d5390e in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=854e61d5390e
description:
configs: fix bug introduced due to 276ad9121192

I had made a typo in changeset 276ad9121192.  This changeset fixes it

diffstat:

 configs/common/HMC.py |  2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diffs (12 lines):

diff -r 2d1d51615e0e -r 854e61d5390e configs/common/HMC.py
--- a/configs/common/HMC.py Tue Nov 03 12:17:58 2015 -0600
+++ b/configs/common/HMC.py Wed Nov 04 12:36:28 2015 -0600
@@ -84,7 +84,7 @@
 from m5.objects import *
 
 # A single Hybrid Memory Cube (HMC)
-class HMCSystem(SimOject):
+class HMCSystem(SimObject):
 
 #*CROSSBAR PARAMETERS*
 # Flit size of the main interconnect [1]
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3158: mem: Add an option to perform clean writebacks from caches

[Andreas Hansson]

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

(Updated Nov. 4, 2015, 5:53 p.m.)


Review request for Default.


Repository: gem5


Description (updated)
---

Changeset 11198:7445f17936f5
---
mem: Add an option to perform clean writebacks from caches

This patch adds the necessary commands and cache functionality to
allow clean writebacks. This functionality is crucial, especially when
having exclusive (victim) caches. For example, if read-only L1
instruction caches are not sending clean writebacks, there will never
be any spills from the L1 to the L2. At the moment the cache model
defaults to not sending clean writebacks, and this should possibly be
re-evaluated.

The implementation of clean writebacks relies on a new packet command
WritebackClean, which acts much like a Writeback (renamed
WritebackDirty), and also much like a CleanEvict. On eviction of a
clean block the cache either sends a clean evict, or a clean
writeback, and if any copies are still cached upstream the clean
evict/writeback is dropped. Similarly, if a clean evict/writeback
reaches a cache where there are outstanding MSHRs for the block, the
packet is dropped. In the typical case though, the clean writeback
allocates a block in the downstream cache, and marks it writable if
the evicted block was writable.

The patch changes the O3_ARM_v7a L1 cache configuration and the
default L1 caches in config/common/Caches.py


Diffs (updated)
-

  src/mem/coherent_xbar.cc 2d1d51615e0e 
  src/mem/packet.hh 2d1d51615e0e 
  src/mem/packet.cc 2d1d51615e0e 
  src/mem/snoop_filter.cc 2d1d51615e0e 
  src/mem/cache/Cache.py 2d1d51615e0e 
  src/mem/cache/base.hh 2d1d51615e0e 
  src/mem/cache/cache.hh 2d1d51615e0e 
  src/mem/cache/cache.cc 2d1d51615e0e 
  configs/common/Caches.py 2d1d51615e0e 
  configs/common/O3_ARM_v7a.py 2d1d51615e0e 
  src/mem/abstract_mem.cc 2d1d51615e0e 

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


Testing
---


Thanks,

Andreas Hansson

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

Re: [gem5-dev] Review Request 3158: mem: Add an option to perform clean writebacks from caches

[Andreas Hansson]

> On Nov. 4, 2015, 7:11 a.m., Steve Reinhardt wrote:
> > src/mem/packet.cc, line 93
> > 
> >
> > do we really want NeedsExclusive set here?
> 
> Andreas Hansson wrote:
> I think we will be able to get away without, but  this is the exclusive 
> copy in the memory system, and if we see something that is going to change 
> that we drop it. Any particular aversions?

Ended up removine NeedsExclusive from both WritebackDirty and WritebackClean. 
They provide exclusive, but never "need" it.


- Andreas


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


On Nov. 2, 2015, 10:44 a.m., Andreas Hansson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3158/
> ---
> 
> (Updated Nov. 2, 2015, 10:44 a.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11192:22b5a5b7c5a3
> ---
> mem: Add an option to perform clean writebacks from caches
> 
> This patch adds the necessary commands and cache functionality to
> allow clean writebacks. This functionality is crucial, especially when
> having exclusive (victim) caches. For example, if read-only L1
> instruction caches are not sending clean writebacks, there will never
> be any spills from the L1 to the L2. At the moment the cache model
> defaults to not sending clean writebacks, and this should possibly be
> re-evaluated.
> 
> The implementation of clean writebacks relies on a new packet command
> WritebackClean, which acts much like a Writeback (renamed
> WritebackDirty), and also much like a CleanEvict. On eviction of a
> clean block the cache either sends a clean evict, or a clean
> writeback, and if any copies are still cached upstream the clean
> evict/writeback is dropped. Similarly, if a clean evict/writeback
> reaches a cache where there are outstanding MSHRs for the block, the
> packet is dropped. In the typical case though, the clean writeback
> allocates a block in the downstream cache, and marks it writable if
> the evicted block was writable.
> 
> The patch changes the O3_ARM_v7a L1 cache configuration and the
> default L1 caches in config/common/Caches.py
> 
> 
> Diffs
> -
> 
>   configs/common/Caches.py 4daf60db14d7 
>   configs/common/O3_ARM_v7a.py 4daf60db14d7 
>   src/mem/abstract_mem.cc 4daf60db14d7 
>   src/mem/cache/Cache.py 4daf60db14d7 
>   src/mem/cache/base.hh 4daf60db14d7 
>   src/mem/cache/cache.hh 4daf60db14d7 
>   src/mem/cache/cache.cc 4daf60db14d7 
>   src/mem/coherent_xbar.cc 4daf60db14d7 
>   src/mem/packet.hh 4daf60db14d7 
>   src/mem/packet.cc 4daf60db14d7 
>   src/mem/snoop_filter.cc 4daf60db14d7 
> 
> Diff: http://reviews.gem5.org/r/3158/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Andreas Hansson
> 
>

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

Re: [gem5-dev] Review Request 3168: misc: Appease clang static analyzer

[Jason Lowe-Power]

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

Ship it!


Ship It!

- Jason Lowe-Power


On Oct. 28, 2015, 8:26 a.m., Andreas Hansson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3168/
> ---
> 
> (Updated Oct. 28, 2015, 8:26 a.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11177:ed03df6d9093
> ---
> misc: Appease clang static analyzer
> 
> A few minor fixes to issues identified by the clang static analyzer.
> 
> 
> Diffs
> -
> 
>   src/mem/ruby/system/RubySystem.cc 741b3059946e 
>   src/mem/stack_dist_calc.cc 741b3059946e 
>   src/base/loader/dtb_object.cc 741b3059946e 
>   src/mem/cache/tags/fa_lru.cc 741b3059946e 
>   src/mem/dram_ctrl.cc 741b3059946e 
>   src/mem/ruby/network/garnet/fixed-pipeline/NetworkInterface_d.hh 
> 741b3059946e 
> 
> Diff: http://reviews.gem5.org/r/3168/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Andreas Hansson
> 
>

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

Re: [gem5-dev] HTM implementation

[Geoffrey Blake]

Hi Rohith,

It is possible to add the code you are suggesting in your message.  You
will also have to modify the simulator atomic CPU models to do the proper
things to not leak memory accesses,  and perform rollback of the
transactional state in case of conflicts in addition to adding your
database based conflict detection and versioning.  If you intend to extend
this to timing mode and the caches you will also have to dig into the cache
coherence and cache models as well unless faking it via the database is
sufficient for your needs.

In the past I had a version of gem5 that had LogTM support for Alpha, and
it appears to still exist at http://www.eecs.umich.edu/~blakeg/ at the
bottom of the page if you want to look at a potential starting point.

Thanks,
Geoff Blake

On Wed, Nov 4, 2015 at 6:00 AM, rohith mathew  wrote:

> Hi all,
>
> I'm trying to implement a syatem with a Hardware Transactional Memory(HTM)
> in gem5 with x86. I just want to know whether it is possible to have a
> database in the main memory for the operation of HTM. If possible can
> anyone give me some suggestions to do that.
>
> Thanks in advance.
>
> regards,
> Rohith
> ___
> 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 3198: x86/cpuid.cc add "family" to warn() message to make them more useful

[Bjoern A. Zeeb]

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

(Updated Nov. 4, 2015, 3:16 p.m.)


Review request for Default.


Repository: gem5


Description
---

doCpuid() has to identical warn messages about unimplemented functions.  Add 
the family to the log message to make them distinguishable.


Diffs
-

  src/arch/x86/cpuid.cc 2d1d51615e0e 

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


Testing
---


Thanks,

Bjoern A. Zeeb

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

[gem5-dev] Review Request 3198: x86/cpuid.cc add "family" to warn() message to make them more useful

[Bjoern A. Zeeb]

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

Review request for Default.


Repository: gem5


Description
---

doCpuid() has to identical warn messages about unimplemented functions.  Add 
the family to the log message to make them distinguishable.


Diffs
-

  src/arch/x86/cpuid.cc 2d1d51615e0e 

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


Testing
---


Thanks,

Bjoern A. Zeeb

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

Re: [gem5-dev] HMC controler breaks FS mode

[Nilay Vaish]

On Wed, 4 Nov 2015, Pierre-Yves Péneau wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dear all,

It seems that the recent commits related to the new HMC interconnect
cause a bug. Given a fresh clone of the gem5 repository, and a classic
build [1], I cannot launch a full system simulation. I have to get back
to 11182:fa8b2a99d4fe to have a working FS simulation.

Here the log:

gem5 Simulator System.  http://gem5.org
gem5 is copyrighted software; use the --copyright option for details.

gem5 compiled Nov  4 2015 15:05:02
gem5 started Nov  4 2015 15:05:47
gem5 executing on jaguar.lirmm.fr, pid 56538
command line: ./build/ARM/gem5.opt configs/example/fs.py

Traceback (most recent call last):
 File "", line 1, in 
 File "/tmp/gem5/src/python/m5/main.py", line 389, in main
   exec filecode in scope
 File "configs/example/fs.py", line 55, in 
   import Ruby
 File "/tmp/gem5/configs/ruby/Ruby.py", line 48, in 
   import MemConfig
 File "/tmp/gem5/configs/common/MemConfig.py", line 42, in 
   import HMC
 File "/tmp/gem5/configs/common/HMC.py", line 87, in 
   class HMCSystem(SimOject):
NameError: name 'SimOject' is not defined




My mistake.  I'll fix it soon.

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

Re: [gem5-dev] changeset in gem5: mem: hmc: top level design

[Erfan Azarkhish]

Dear Nilay and Andreas,

There is a typo in this changeset which is causing an error:

*SimOject *==> must  be *SimObject*

Also, I guess you have agreed on changing *Subsystem *to *Simobject*, is it
correct?

Thanks,


On Tue, Nov 3, 2015 at 10:12 PM, Erfan Azarkhish 
wrote:

> changeset 276ad9121192 in /z/repo/gem5
> details: http://repo.gem5.org/gem5?cmd=changeset;node=276ad9121192
> description:
> mem: hmc: top level design
>
> This patch enables modeling a complete Hybrid Memory Cube (HMC)
> device. It
> highly reuses the existing components in gem5's general memory
> system with some
> small modifications. This changeset requires additional patches to
> model a
> complete HMC device.
>
> Committed by: Nilay Vaish 
>
> diffstat:
>
>  configs/common/HMC.py   |  238
> 
>  configs/common/MemConfig.py |   21 ++-
>  configs/example/fs.py   |1 +
>  3 files changed, 254 insertions(+), 6 deletions(-)
>
> diffs (truncated from 306 to 300 lines):
>
> diff -r fa8b2a99d4fe -r 276ad9121192 configs/common/HMC.py
> --- /dev/null   Thu Jan 01 00:00:00 1970 +
> +++ b/configs/common/HMC.py Tue Nov 03 12:17:56 2015 -0600
> @@ -0,0 +1,238 @@
> +# Copyright (c) 2012-2013 ARM Limited
> +# All rights reserved.
> +#
> +# The license below extends only to copyright in the software and shall
> +# not be construed as granting a license to any other intellectual
> +# property including but not limited to intellectual property relating
> +# to a hardware implementation of the functionality of the software
> +# licensed hereunder.  You may use the software subject to the license
> +# terms below provided that you ensure that this notice is replicated
> +# unmodified and in its entirety in all distributions of the software,
> +# modified or unmodified, in source code or in binary form.
> +#
> +# Copyright (c) 2015 The University of Bologna
> +# All rights reserved.
> +#
> +# Redistribution and use in source and binary forms, with or without
> +# modification, are permitted provided that the following conditions are
> +# met: redistributions of source code must retain the above copyright
> +# notice, this list of conditions and the following disclaimer;
> +# redistributions in binary form must reproduce the above copyright
> +# notice, this list of conditions and the following disclaimer in the
> +# documentation and/or other materials provided with the distribution;
> +# neither the name of the copyright holders nor the names of its
> +# contributors may be used to endorse or promote products derived from
> +# this software without specific prior written permission.
> +#
> +# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
> +# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
> +# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
> +# A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
> +# OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
> +# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
> +# LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
> +# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
> +# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
> +# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
> +# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> +#
> +# Authors: Erfan Azarkhish
> +
> +# A Simplified model of a complete HMC device. Based on:
> +#  [1] http://www.hybridmemorycube.org/specification-download/
> +#  [2] High performance AXI-4.0 based interconnect for extensible smart
> memory
> +#  cubes(E. Azarkhish et. al)
> +#  [3] Low-Power Hybrid Memory Cubes With Link Power Management and
> Two-Level
> +#  Prefetching (J. Ahn et. al)
> +#  [4] Memory-centric system interconnect design with Hybrid Memory Cubes
> +#  (G. Kim et. al)
> +#  [5] Near Data Processing, Are we there yet? (M. Gokhale)
> +#  http://www.cs.utah.edu/wondp/gokhale.pdf
> +#
> +# This script builds a complete HMC device composed of vault controllers,
> +# serial links, the main internal crossbar, and an external hmc
> controller.
> +#
> +# - VAULT CONTROLLERS:
> +#   Instances of the HMC_2500_x32 class with their functionality
> specified in
> +#   dram_ctrl.cc
> +#
> +# - THE MAIN XBAR:
> +#   This component is simply an instance of the NoncoherentXBar class,
> and its
> +#   parameters are tuned to [2].
> +#
> +# - SERIAL LINKS:
> +#   SerialLink is a simple variation of the Bridge class, with the
> ability to
> +#   account for the latency of packet serialization. We assume that the
> +#   serializer component at the transmitter side does not need to receive
> the
> +#   whole packet to start the serialization. But the deserializer waits
> for
> +#   the complete packet to check its integrity first.
> +#   * Ban

Re: [gem5-dev] Review Request 3194: Properly space pad the X86IntelMPBus Entry descriptions.

[Bjoern A. Zeeb]

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

(Updated Nov. 4, 2015, 2:51 p.m.)


Review request for Default.


Changes
---

Also update the documenting comment in the class.


Repository: gem5


Description
---

According to the Intel Multi Processor Specification rev 1.4 (-006) (*), 
section 4.3.2 Bus Entries, Bus type strings are >>6-character ASCII 
(blank-filled) strings<<.
Properly pad the entries with the missing spaces at the end.

(*) http://www.intel.com/design/pentium/datashts/24201606.pdf


Diffs (updated)
-

  src/arch/x86/bios/IntelMP.py 2d1d51615e0e 
  configs/common/FSConfig.py 2d1d51615e0e 

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


Testing
---

Booting FreeBSD in FS mode no longer complains about unknown busses "PCI" and 
"ISA".


Thanks,

Bjoern A. Zeeb

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

Re: [gem5-dev] HMC controler breaks FS mode

[Erfan Azarkhish]

Dear Pierre,

I am responsible for the patches on HMC. In your logs I see something
strange:
Class HMCSystem is supposed to be inherited from Subsystem class and not
Simobject:
http://reviews.gem5.org/r/2986/   -- LINE 91

Maybe this is due to incorrect order of the patches. Because in my MQ the
order of the patches is the following:
1- hmccontroller3173
2- seriallink   2993
3- minorfix 3174
4- hmc  2986

But in the repository the patches are applied in the following order:
1. hmc
2. hmccontroller
3. seriallink
4. minorfix

Could someone please help with this problem?

Thanks,

Erfan,

On Wed, Nov 4, 2015 at 5:46 PM, Pierre-Yves Péneau <
pierre-yves.pen...@lirmm.fr> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Dear all,
>
> It seems that the recent commits related to the new HMC interconnect
> cause a bug. Given a fresh clone of the gem5 repository, and a classic
> build [1], I cannot launch a full system simulation. I have to get back
> to 11182:fa8b2a99d4fe to have a working FS simulation.
>
> Here the log:
>
> gem5 Simulator System.  http://gem5.org
> gem5 is copyrighted software; use the --copyright option for details.
>
> gem5 compiled Nov  4 2015 15:05:02
> gem5 started Nov  4 2015 15:05:47
> gem5 executing on jaguar.lirmm.fr, pid 56538
> command line: ./build/ARM/gem5.opt configs/example/fs.py
>
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "/tmp/gem5/src/python/m5/main.py", line 389, in main
> exec filecode in scope
>   File "configs/example/fs.py", line 55, in 
> import Ruby
>   File "/tmp/gem5/configs/ruby/Ruby.py", line 48, in 
> import MemConfig
>   File "/tmp/gem5/configs/common/MemConfig.py", line 42, in 
> import HMC
>   File "/tmp/gem5/configs/common/HMC.py", line 87, in 
> class HMCSystem(SimOject):
> NameError: name 'SimOject' is not defined
>
>
> Best regards,
>
> [1] scons build/ARM/gem5.opt
> - --
> +--+
> | Pierre-Yves Péneau|  first.last at lirmm.fr  |
> | PhD student - LIRMM - Sysmic  |+ 33 4 67 41 85 85|
> | Bâtiment 4 Bureau H2.2|http://walafc0.org|
> +--+
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
>
> iQIcBAEBAgAGBQJWOhMhAAoJEPy7VC2L9m/AaIMP+wTmnyIDhsyBqMZLk8Be7OB0
> B9HssZCd4qEuMrxcVVNvKuY77qftHkido4O4Sa/bsrCWFQa7proNKhPi1hbqBp48
> qfQ2ZFYWJR/ZY10gSEh86x4WwC76GVMKT2QkWwUHS6P7oOU1PcKdoLlOvQjtlX9z
> Y3MmcGArZWDkNl1ut/4I1MnlIJiAC0On0FNWUBCQqwlg//NvleIpYJuhYXF3ZbOS
> 8DgV7lo0zbkeLCzuo4fuKLR/xQppxHsXOpI8Ma2g4YAbtcdk3roEpdRhmz6iQN7U
> tRTvaVwNSsSv1MpTMRLT6q24YlKazaI9vqA7ppwfg55EwYJDn6IiFTbtu6Xcr9rA
> d7KJEjXR4RXxSF0XAM/sPutMpWC8wfcNWoabnPQ0PYLCrZY3gob6Ua0hZJE5ZmON
> VJa9ut5EmjGn1Q7t6gIy9jVQHi2hcCuLPT69pzDd6S+3cE7Tciyj/lhLxxihS8sM
> j7CxYbpNWLOhaxnQEfLJdj50ijJrag4b5aTklnuAdE24JfkRtuTVWINCWnpDebbE
> 6GravJYbH33GN5Aq4d8m7PpuN2qxElN4poWkgmiOGMUiDyGz3eOv3RKvAcDX3nCP
> DFZYRAQErHru4U8SjeQW5dpVWuJaDXM/3KvHF7eJ4i1suS3JhYGvvZB6GDlCPuWQ
> VVeBeAJaBnCiwsXRLufO
> =drIG
> -END PGP SIGNATURE-
> ___
> gem5-dev mailing list
> gem5-dev@gem5.org
> http://m5sim.org/mailman/listinfo/gem5-dev
>



-- 
Erfan Azarkhish
Micrel Lab - Viale Carlo Pepoli 3/2 - 40123, Bologna
DEI - University of Bologna, Italy
https://www.linkedin.com/in/erfanazarkhish
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] Review Request 3197: Fix typo

[Bjoern A. Zeeb]

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

Review request for Default.


Repository: gem5


Description
---

Now that we know ..


Diffs
-

  src/arch/x86/pagetable_walker.cc 2d1d51615e0e 

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


Testing
---


Thanks,

Bjoern A. Zeeb

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

[gem5-dev] Review Request 3195: gcc is not cc

[Bjoern A. Zeeb]

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

Review request for Default.


Repository: gem5


Description
---

With clang there are systems without "gcc" being installed anymore and we 
should not rely on that.  Use "cc" instead and make it compile on these systems.


Diffs
-

  util/term/Makefile 2d1d51615e0e 

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


Testing
---


Thanks,

Bjoern A. Zeeb

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

Re: [gem5-dev] Review Request 3196: tcp_iface.cc does not compile on FreeBSD

[Bjoern A. Zeeb]

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

(Updated Nov. 4, 2015, 2:39 p.m.)


Review request for Default.


Repository: gem5


Description
---

To compile tcp_iface.cc on FreeBSD we also need to include netinet/in.h.  Do so 
conditinally for FreeBSD.


Diffs
-

  src/dev/tcp_iface.cc 2d1d51615e0e 

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


Testing
---

Compiles now.


Thanks,

Bjoern A. Zeeb

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

[gem5-dev] Review Request 3196: tcp_iface.cc does not compile on FreeBSD

[Bjoern A. Zeeb]

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

Review request for Default.


Repository: gem5


Description
---

To compile tcp_iface.cc on FreeBSD we also need to include netinet/in.h.  Do so 
conditinally for FreeBSD.


Diffs
-

  src/dev/tcp_iface.cc 2d1d51615e0e 

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


Testing
---

Compiles now.


Thanks,

Bjoern A. Zeeb

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

[gem5-dev] HMC controler breaks FS mode

[Pierre-Yves Péneau]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dear all,

It seems that the recent commits related to the new HMC interconnect
cause a bug. Given a fresh clone of the gem5 repository, and a classic
build [1], I cannot launch a full system simulation. I have to get back
to 11182:fa8b2a99d4fe to have a working FS simulation.

Here the log:

gem5 Simulator System.  http://gem5.org
gem5 is copyrighted software; use the --copyright option for details.

gem5 compiled Nov  4 2015 15:05:02
gem5 started Nov  4 2015 15:05:47
gem5 executing on jaguar.lirmm.fr, pid 56538
command line: ./build/ARM/gem5.opt configs/example/fs.py

Traceback (most recent call last):
  File "", line 1, in 
  File "/tmp/gem5/src/python/m5/main.py", line 389, in main
exec filecode in scope
  File "configs/example/fs.py", line 55, in 
import Ruby
  File "/tmp/gem5/configs/ruby/Ruby.py", line 48, in 
import MemConfig
  File "/tmp/gem5/configs/common/MemConfig.py", line 42, in 
import HMC
  File "/tmp/gem5/configs/common/HMC.py", line 87, in 
class HMCSystem(SimOject):
NameError: name 'SimOject' is not defined


Best regards,

[1] scons build/ARM/gem5.opt
- -- 
+--+
| Pierre-Yves Péneau|  first.last at lirmm.fr  |
| PhD student - LIRMM - Sysmic  |+ 33 4 67 41 85 85|
| Bâtiment 4 Bureau H2.2|http://walafc0.org|
+--+
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJWOhMhAAoJEPy7VC2L9m/AaIMP+wTmnyIDhsyBqMZLk8Be7OB0
B9HssZCd4qEuMrxcVVNvKuY77qftHkido4O4Sa/bsrCWFQa7proNKhPi1hbqBp48
qfQ2ZFYWJR/ZY10gSEh86x4WwC76GVMKT2QkWwUHS6P7oOU1PcKdoLlOvQjtlX9z
Y3MmcGArZWDkNl1ut/4I1MnlIJiAC0On0FNWUBCQqwlg//NvleIpYJuhYXF3ZbOS
8DgV7lo0zbkeLCzuo4fuKLR/xQppxHsXOpI8Ma2g4YAbtcdk3roEpdRhmz6iQN7U
tRTvaVwNSsSv1MpTMRLT6q24YlKazaI9vqA7ppwfg55EwYJDn6IiFTbtu6Xcr9rA
d7KJEjXR4RXxSF0XAM/sPutMpWC8wfcNWoabnPQ0PYLCrZY3gob6Ua0hZJE5ZmON
VJa9ut5EmjGn1Q7t6gIy9jVQHi2hcCuLPT69pzDd6S+3cE7Tciyj/lhLxxihS8sM
j7CxYbpNWLOhaxnQEfLJdj50ijJrag4b5aTklnuAdE24JfkRtuTVWINCWnpDebbE
6GravJYbH33GN5Aq4d8m7PpuN2qxElN4poWkgmiOGMUiDyGz3eOv3RKvAcDX3nCP
DFZYRAQErHru4U8SjeQW5dpVWuJaDXM/3KvHF7eJ4i1suS3JhYGvvZB6GDlCPuWQ
VVeBeAJaBnCiwsXRLufO
=drIG
-END PGP SIGNATURE-
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3156: mem: Add cache clusivity

[Andreas Hansson]

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

(Updated Nov. 4, 2015, 12:52 p.m.)


Review request for Default.


Repository: gem5


Description (updated)
---

Changeset 11195:8bf51d20200d
---
mem: Add cache clusivity

This patch adds a parameter to control the cache clusivity, that is if
the cache is mostly inclusive or exclusive. At the moment there is no
intention to support strict policies, and thus the options are: 1)
mostly inclusive, or 2) mostly exclusive.

The choice of policy guides the behaviuor on a cache fill, and a new
helper function, allocOnFill, is created to encapsulate the decision
making process. For the timing mode, the decision is annotated on the
MSHR on sending out the downstream packet, and in atomic we directly
pass the decision to handleFill. We (ab)use the tempBlock in cases
where we are not allocating on fill, leaving the rest of the cache
unaffected. Simple and effective.

This patch also makes it more explicit that multiple caches are
allowed to consider a block writable (this is the case
also before this patch). That is, for a mostly inclusive cache,
multiple caches upstream may also consider the block exclusive. The
caches considering the block writable/exclusive all appear along the
same path to memory, and from a coherency protocol point of view it
works due to the fact that we always snoop upwards in zero time before
querying any downstream cache.

Note that this patch does not introduce clean writebacks. Thus, for
clean lines we are essentially removing a cache level if it is made
mostly exclusive. For example, lines from the read-only L1 instruction
cache or table-walker cache are always clean, and simply get dropped
rather than being passed to the L2. If the L2 is mostly exclusive and
does not allocate on fill it will thus never hold the line. A follow
on patch adds the clean writebacks.

The patch changes the L2 of the O3_ARM_v7a CPU configuration to be
mostly exclusive (and stats are affected accordingly).


Diffs (updated)
-

  configs/common/O3_ARM_v7a.py 2d1d51615e0e 
  src/mem/cache/Cache.py 2d1d51615e0e 
  src/mem/cache/base.hh 2d1d51615e0e 
  src/mem/cache/cache.hh 2d1d51615e0e 
  src/mem/cache/cache.cc 2d1d51615e0e 
  src/mem/cache/mshr.hh 2d1d51615e0e 
  src/mem/cache/mshr.cc 2d1d51615e0e 
  src/mem/cache/mshr_queue.hh 2d1d51615e0e 
  src/mem/cache/mshr_queue.cc 2d1d51615e0e 

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


Testing
---


Thanks,

Andreas Hansson

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

[gem5-dev] HTM implementation

[rohith mathew]

Hi all,

I'm trying to implement a syatem with a Hardware Transactional Memory(HTM)
in gem5 with x86. I just want to know whether it is possible to have a
database in the main memory for the operation of HTM. If possible can
anyone give me some suggestions to do that.

Thanks in advance.

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

Re: [gem5-dev] Review Request 3172: mem: Use the packet delays and do not just zero them out

[Andreas Hansson]

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

(Updated Nov. 4, 2015, 9:34 a.m.)


Review request for Default.


Repository: gem5


Description (updated)
---

Changeset 11191:d5063101794c
---
mem: Use the packet delays and do not just zero them out

This patch updates the I/O devices, bridge and simple memory to take
the packet header and payload delay into account in their latency
calculations. In all cases we add the header delay, i.e. the
accumulated pipeline delay of any crossbars, and the payload delay
needed for deserialisation of any payload.

Due to the additional unknown latency contribution, the packet queue
of the simple memory is changed to use insertion sorting based on the
time stamp. Moreover, since the memory hands out exclusive (non
shared) responses, we also need to ensure ordering for reads to the
same address.


Diffs (updated)
-

  src/dev/io_device.cc 2d1d51615e0e 
  src/dev/pcidev.cc 2d1d51615e0e 
  src/mem/bridge.cc 2d1d51615e0e 
  src/mem/simple_mem.hh 2d1d51615e0e 
  src/mem/simple_mem.cc 2d1d51615e0e 

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


Testing
---


Thanks,

Andreas Hansson

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

Re: [gem5-dev] Review Request 3156: mem: Add cache clusivity

[Andreas Hansson]

> On Nov. 4, 2015, 6:41 a.m., Steve Reinhardt wrote:
> > src/mem/cache/cache.hh, line 291
> > 
> >
> > it would be much more in the style of Packet to add an AlwaysAlloc 
> > value to Packet::Attribute (and a corresponding alwaysAlloc() method to 
> > test it), then add that attribute to the appropriate commands in 
> > MemCmd::commandInfo[] in packet.cc.  Then this test would just be
> > 
> >   clusivity == Enums::mostly_incl || pkt->alwaysAlloc()
> > 
> > That would also make it clear that the decision needs to be made for 
> > each command type; with lists like this it's always easy to think you have 
> > it covered but leave one out.

I am tempted to rather make the flag "FromCache" or similar to also be useful 
for the tests in the cache that surrounds how we response upwards. I would 
prefer to shift this to a follow-on patch to not make this more complex than it 
already is.


> On Nov. 4, 2015, 6:41 a.m., Steve Reinhardt wrote:
> > src/mem/cache/cache.hh, line 295
> > 
> >
> > doesn't ReadReq include most reads?  seems like mostly_excl would not 
> > be mostly exclusive then.

ReadReq is never issues by a cache, this by checking for it we now that it came 
from a non-cache (CPU, table walker, device etc). This comes back to my 
previous point about having a "FromCache" attribute.


> On Nov. 4, 2015, 6:41 a.m., Steve Reinhardt wrote:
> > src/mem/cache/cache.hh, line 294
> > 
> >
> > why not MemCmd::Writeback?

We never fill writebacks. The allocation of writebacks from above is thus never 
querying this function.


> On Nov. 4, 2015, 6:41 a.m., Steve Reinhardt wrote:
> > src/mem/cache/cache.cc, line 207
> > 
> >
> > with these three lines showing up repeatedly, might be worth defining a 
> > helper function on Cache, e.g., Cache::invalidate(CacheBlk *)

Sure, we can do so.


> On Nov. 4, 2015, 6:41 a.m., Steve Reinhardt wrote:
> > src/mem/cache/cache.cc, line 275
> > 
> >
> > so is it the case that tempBlock could never have been allocated for a 
> > writable block before?  I don't see anything that prevents that.  Did we 
> > always just get lucky?

We just got lucky.


> On Nov. 4, 2015, 6:41 a.m., Steve Reinhardt wrote:
> > src/mem/cache/cache.cc, line 1097
> > 
> >
> > I'm confused as to why the writeback of tempBlock is treated 
> > differently from all the other writebacks.

I am not sure I understand your question. Is it "why don't we just stick it on 
the list of writebacks"?


> On Nov. 4, 2015, 6:41 a.m., Steve Reinhardt wrote:
> > src/mem/cache/cache.cc, line 2352
> > 
> >
> > should be '||='?
> > 
> > Also, it seems a little odd that we wait until we're issuing the 
> > request to look at the target packets and decide whether to allocate or 
> > not.  Couldn't we look at the commands as we add the targets to the MSHR?

Is there such a thing?

I will look into the possibility of moving it. I'm not terribly happy with how 
it is done currently.


- Andreas


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


On Nov. 2, 2015, 10:44 a.m., Andreas Hansson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3156/
> ---
> 
> (Updated Nov. 2, 2015, 10:44 a.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11190:df17c209342a
> ---
> mem: Add cache clusivity
> 
> This patch adds a parameter to control the cache clusivity, that is if
> the cache is mostly inclusive or exclusive. At the moment there is no
> intention to support strict policies, and thus the options are: 1)
> mostly inclusive, or 2) mostly exclusive.
> 
> The choice of policy guides the behaviuor on a cache fill, and a new
> helper function, allocOnFill, is created to encapsulate the decision
> making process. For the timing mode, the decision is annotated on the
> MSHR on sending out the downstream packet, and in atomic we directly
> pass the decision to handleFill. We (ab)use the tempBlock in cases
> where we are not allocating on fill, leaving the rest of the cache
> unaffected. Simple and effective.
> 
> This patch also makes it more explicit that multiple caches are
> allowed to consider a 

Re: [gem5-dev] Review Request 3158: mem: Add an option to perform clean writebacks from caches

[Andreas Hansson]

> On Nov. 4, 2015, 7:11 a.m., Steve Reinhardt wrote:
> > src/mem/packet.hh, line 148
> > 
> >
> > maybe instead of IsWriteback, we should add IsEviction, and set that on 
> > all three commands
> > 
> > then we could:
> >  - replace evictingBlock() with isEviction()
> >  - define isWriteback() as isEviction() && hasData()
> >  - create an isCleanEviction() that is isEviction() && 
> > !needsExclusive() (assuming we get rid of NeedsExclusive on 
> > WritebackClean), and use that to replace all the "== CleanEvict || == 
> > WritebackClean" expressions

I would prefer the addition of "IsEviction" to be in a separate follow-on patch.


> On Nov. 4, 2015, 7:11 a.m., Steve Reinhardt wrote:
> > src/mem/cache/cache.cc, line 1154
> > 
> >
> > minor, but I think this would be more readable with parens around the 
> > condition, and with the RHS actually to the right of the '=', e.g.:
> > 
> > tempBlockWriteback = (blk->isDirty() || writebackClean) ?
> >   writebackBlk(blk) : cleanEvictBlk(blk);
> > 
> > or if not that, then perhaps
> > 
> > bool do_wb = blk->isDirty() || writebackClean;
> > tempBlockWriteback = do_wb ? ritebackBlk(blk) : 
> > cleanEvictBlk(blk);

Sure. Will do.


> On Nov. 4, 2015, 7:11 a.m., Steve Reinhardt wrote:
> > src/mem/packet.cc, line 93
> > 
> >
> > do we really want NeedsExclusive set here?

I think we will be able to get away without, but  this is the exclusive copy in 
the memory system, and if we see something that is going to change that we drop 
it. Any particular aversions?


- Andreas


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


On Nov. 2, 2015, 10:44 a.m., Andreas Hansson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3158/
> ---
> 
> (Updated Nov. 2, 2015, 10:44 a.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11192:22b5a5b7c5a3
> ---
> mem: Add an option to perform clean writebacks from caches
> 
> This patch adds the necessary commands and cache functionality to
> allow clean writebacks. This functionality is crucial, especially when
> having exclusive (victim) caches. For example, if read-only L1
> instruction caches are not sending clean writebacks, there will never
> be any spills from the L1 to the L2. At the moment the cache model
> defaults to not sending clean writebacks, and this should possibly be
> re-evaluated.
> 
> The implementation of clean writebacks relies on a new packet command
> WritebackClean, which acts much like a Writeback (renamed
> WritebackDirty), and also much like a CleanEvict. On eviction of a
> clean block the cache either sends a clean evict, or a clean
> writeback, and if any copies are still cached upstream the clean
> evict/writeback is dropped. Similarly, if a clean evict/writeback
> reaches a cache where there are outstanding MSHRs for the block, the
> packet is dropped. In the typical case though, the clean writeback
> allocates a block in the downstream cache, and marks it writable if
> the evicted block was writable.
> 
> The patch changes the O3_ARM_v7a L1 cache configuration and the
> default L1 caches in config/common/Caches.py
> 
> 
> Diffs
> -
> 
>   configs/common/Caches.py 4daf60db14d7 
>   configs/common/O3_ARM_v7a.py 4daf60db14d7 
>   src/mem/abstract_mem.cc 4daf60db14d7 
>   src/mem/cache/Cache.py 4daf60db14d7 
>   src/mem/cache/base.hh 4daf60db14d7 
>   src/mem/cache/cache.hh 4daf60db14d7 
>   src/mem/cache/cache.cc 4daf60db14d7 
>   src/mem/coherent_xbar.cc 4daf60db14d7 
>   src/mem/packet.hh 4daf60db14d7 
>   src/mem/packet.cc 4daf60db14d7 
>   src/mem/snoop_filter.cc 4daf60db14d7 
> 
> Diff: http://reviews.gem5.org/r/3158/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Andreas Hansson
> 
>

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

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

[Cron Daemon]

* build/ALPHA/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby FAILED!
* 
build/ALPHA_MOESI_hammer/tests/opt/quick/se/60.rubytest/alpha/linux/rubytest-ruby-MOESI_hammer
 FAILED!
* 
build/ALPHA_MOESI_hammer/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby-MOESI_hammer
 FAILED!
* 
build/ALPHA_MOESI_hammer/tests/opt/quick/se/00.hello/alpha/linux/simple-timing-ruby-MOESI_hammer
 FAILED!
* 
build/ALPHA_MOESI_hammer/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing-ruby-MOESI_hammer
 FAILED!
* 
build/ALPHA_MESI_Two_Level/tests/opt/quick/se/60.rubytest/alpha/linux/rubytest-ruby-MESI_Two_Level
 FAILED!
* 
build/ALPHA_MESI_Two_Level/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby-MESI_Two_Level
 FAILED!
* 
build/ALPHA_MESI_Two_Level/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing-ruby-MESI_Two_Level
 FAILED!
* 
build/ALPHA_MESI_Two_Level/tests/opt/quick/se/00.hello/alpha/linux/simple-timing-ruby-MESI_Two_Level
 FAILED!
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/simple-timing-ruby 
FAILED!
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing-ruby 
FAILED!
* build/ALPHA/tests/opt/quick/se/60.rubytest/alpha/linux/rubytest-ruby 
FAILED!
* 
build/ALPHA_MOESI_CMP_directory/tests/opt/quick/se/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_directory
 FAILED!
* 
build/ALPHA_MOESI_CMP_directory/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_directory
 FAILED!
* 
build/ALPHA_MOESI_CMP_directory/tests/opt/quick/se/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_directory
 FAILED!
* 
build/ALPHA_MOESI_CMP_directory/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby-MOESI_CMP_directory
 FAILED!
* 
build/ALPHA_MOESI_CMP_token/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_token
 FAILED!
* 
build/ALPHA_MOESI_CMP_token/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby-MOESI_CMP_token
 FAILED!
* 
build/ALPHA_MOESI_CMP_token/tests/opt/quick/se/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_token
 FAILED!
* 
build/ALPHA_MOESI_CMP_token/tests/opt/quick/se/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_token
 FAILED!
* build/MIPS/tests/opt/quick/se/00.hello/mips/linux/simple-timing-ruby 
FAILED!
* build/SPARC/tests/opt/quick/se/00.hello/sparc/linux/simple-timing-ruby 
FAILED!
* build/X86/tests/opt/quick/se/00.hello/x86/linux/simple-timing-ruby FAILED!
* build/X86/tests/opt/quick/fs/10.linux-boot/x86/linux/pc-simple-timing 
CHANGED!
scons: *** Error 1
scons: *** Error 1
scons: *** Error 1
scons: *** Error 1
scons: *** Error 1
scons: *** Error 1
scons: *** Error 1
scons: *** Error 1
scons: *** Error 1
scons: *** Error 1
scons: *** Error 1
scons: *** Error 1
scons: *** Error 1
scons: *** Error 1
scons: *** Error 1
scons: *** Error 1
scons: *** Error 1
scons: *** Error 1
scons: *** Error 1
scons: *** Error 1
scons: *** Error 1
scons: *** Error 1
scons: *** Error 1
scons: *** Error 1
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/o3-timing passed.
* build/ALPHA/tests/opt/quick/se/20.eio-short/alpha/eio/simple-atomic 
passed.
* 
build/ALPHA/tests/opt/quick/se/03.learning-gem5/alpha/linux/learning-gem5-p1-two-level
 passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/simple-atomic passed.
* build/ALPHA/tests/opt/quick/se/30.eio-mp/alpha/eio/simple-atomic-mp 
passed.
* 
build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-atomic 
passed.
* build/ALPHA/tests/opt/quick/se/20.eio-short/alpha/eio/simple-timing 
passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/minor-timing passed.
* 
build/ALPHA/tests/opt/quick/se/03.learning-gem5/alpha/linux/learning-gem5-p1-simple
 passed.
* build/ALPHA/tests/opt/quick/se/01.hello-2T-smt/alpha/linux/o3-timing-mt 
passed.
* 
build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-atomic-dual
 passed.
* build/ALPHA/tests/opt/quick/se/50.vortex/alpha/tru64/simple-atomic passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/simple-atomic passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/minor-timing passed.
* 
build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-timing 
passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/simple-timing passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/o3-timing passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing passed.
* build/ALPHA/tests/opt/quick/se/30.eio-mp/alpha/eio/simple-timing-mp 
passed.
* build/ALPHA/tests/opt/quick/se/50.vortex/alpha/tru64/simple-timing passed.
* 
build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-timing-dual
 passed.
* build/ALPHA/tests/opt/quick/se/70.twolf/alpha/tru64/simple-atomic passed.
* 
build/MIPS/tests/opt/quick/se/03.learning-gem5/mips/linux/learning-gem5-p1-two-level
 passed.