date:20180320

Re: [gem5-dev] Multicore ARM v8 KVM based simulation

2018-03-20 Thread Gabe Black

My next question is about disks. I see that the fs_bigLITTLE.py script uses
PciVirtIO to set up its disks, where I'm using IDE which I inherited from
the fs.py scripts I used as reference. The problem I'm seeing is that the
IDE controllers seem to be mangling commands and dropping interrupts, so
this difference looks particularly suspicious. Is there a KVM related
reason you're using PciVirtIO? Is this something that *should* work with
IDE bug doesn't, or do I have to use PciVirtIO for things to work properly?
I'm not familiar with PciVirtIO beyond briefly skimming the source for it
in gem5. Is this something we should consider using globally as a
replacement for IDE, even in simulations where we're trying to be really
realistic?

Thanks again for all the help.

Gabe

On Tue, Mar 20, 2018 at 3:14 PM, Gabe Black  wrote:

> Ok, that (multiple event queues) made things way better. There are still
> some glitches to figure out, but at least it makes good forward progress at
> a reasonable speed. Thanks!
>
> Gabe
>
> On Mon, Mar 19, 2018 at 5:12 PM, Gabe Black  wrote:
>
>> This is on an chromebook based on the RK3399 with only ~4GB of RAM which
>> is not ideal, although we have a bigger machine in the works for the
>> future. I agree with your reasoning and don't think option 1 is a problem.
>> We're using static DTBs so I don't think that's an issue either. In my
>> script, I'm not doing anything smart with the event queues, so that's
>> likely at least part of the problem. When I tried using fs_bigLITTLE.py I
>> ran into what looked like a similar issue so that might not be the whole
>> story, but it's definitely something I should fix up. I'll let you know how
>> that goes!
>>
>> Gabe
>>
>> On Mon, Mar 19, 2018 at 4:30 AM, Andreas Sandberg <
>> andreas.sandb...@arm.com> wrote:
>>
>>> Hmm, OK, this is very strange.
>>>
>>> What type of hardware are you running on? Is it an A57-based chip or
>>> something else? Also, what's your simulation quantum? I have been able to
>>> run with a 0.5ms quantum  (5e8 ticks).
>>> I think the following trace of two CPUs running in KVM should be roughly
>>> equivalent to the trace you shared earlier. It was generated on a
>>> commercially available 8xA57 (16GiB ram) using the following command (gem5
>>> rev 9dc44b417):
>>>
>>> gem5.opt -r --debug-flags Kvm,KvmIO,KvmRun 
>>> configs/example/arm/fs_bigLITTLE.py \
>>> --sim-quantum '0.5ms' \
>>> --cpu-type kvm --big-cpus 0 --little-cpus 2 \
>>> --dtb system/arm/dt/armv8_gem5_v1_2cpu.dtb --kernel 
>>> vmlinux.aarch64.4.4-d318f95d0c
>>>
>>> Note that the tick counts are a bit weird since we have three different
>>> event queues at play (1 for devices and one per CPU).
>>>
>>>   0: system.littleCluster.cpus0: KVM: Executing for 5 ticks
>>>   0: system.littleCluster.cpus1: KVM: Executing for 5 ticks
>>>   0: system.littleCluster.cpus0: KVM: Executed 79170 instructions in 
>>> 176363 cycles (88181504 ticks, sim cycles: 176363).
>>> 88182000: system.littleCluster.cpus0: handleKvmExit (exit_reason: 6)
>>> 88182000: system.littleCluster.cpus0: KVM: Handling MMIO (w: 1, addr: 
>>> 0x1c090024, len: 4)
>>> 88332000: system.littleCluster.cpus0: Entering KVM...
>>> 88332000: system.littleCluster.cpus0: KVM: Executing for 411668000 ticks
>>> 88332000: system.littleCluster.cpus0: KVM: Executed 4384 instructions in 
>>> 16854 cycles (8427000 ticks, sim cycles: 16854).
>>> 96759000: system.littleCluster.cpus0: handleKvmExit (exit_reason: 6)
>>> 96759000: system.littleCluster.cpus0: KVM: Handling MMIO (w: 1, addr: 
>>> 0x1c090030, len: 4)
>>>   0: system.littleCluster.cpus1: KVM: Executed 409368 instructions in 
>>> 666400 cycles (33320 ticks, sim cycles: 666400).
>>> 33320: system.littleCluster.cpus1: Entering KVM...
>>> 33320: system.littleCluster.cpus1: KVM: Executing for 16680 ticks
>>> 96909000: system.littleCluster.cpus0: Entering KVM...
>>> 96909000: system.littleCluster.cpus0: KVM: Executing for 403091000 ticks
>>> 96909000: system.littleCluster.cpus0: KVM: Executed 4384 instructions in 
>>> 15257 cycles (7628500 ticks, sim cycles: 15257).
>>> 104538000: system.littleCluster.cpus0: handleKvmExit (exit_reason: 6)
>>> 104538000: system.littleCluster.cpus0: KVM: Handling MMIO (w: 1, addr: 
>>> 0x1c0100a0, len: 4)
>>> 33320: system.littleCluster.cpus1: KVM: Executed 47544 instructions in 
>>> 200820 cycles (10041 ticks, sim cycles: 200820).
>>> 43361: system.littleCluster.cpus1: Entering KVM...
>>> 43361: system.littleCluster.cpus1: KVM: Executing for 6639 ticks
>>> 104688000: system.littleCluster.cpus0: Entering KVM...
>>> 104688000: system.littleCluster.cpus0: KVM: Executing for 395312000 ticks
>>> 104688000: system.littleCluster.cpus0: KVM: Executed 4382 instructions in 
>>> 14942 cycles (7471000 ticks, sim cycles: 14942).
>>>
>>> Comparing this trace to yours, I'd say that there the frequent KVM exits
>>> look a bit

Re: [gem5-dev] Multicore ARM v8 KVM based simulation

2018-03-20 Thread Gabe Black

Ok, that (multiple event queues) made things way better. There are still
some glitches to figure out, but at least it makes good forward progress at
a reasonable speed. Thanks!

Gabe

On Mon, Mar 19, 2018 at 5:12 PM, Gabe Black  wrote:

> This is on an chromebook based on the RK3399 with only ~4GB of RAM which
> is not ideal, although we have a bigger machine in the works for the
> future. I agree with your reasoning and don't think option 1 is a problem.
> We're using static DTBs so I don't think that's an issue either. In my
> script, I'm not doing anything smart with the event queues, so that's
> likely at least part of the problem. When I tried using fs_bigLITTLE.py I
> ran into what looked like a similar issue so that might not be the whole
> story, but it's definitely something I should fix up. I'll let you know how
> that goes!
>
> Gabe
>
> On Mon, Mar 19, 2018 at 4:30 AM, Andreas Sandberg <
> andreas.sandb...@arm.com> wrote:
>
>> Hmm, OK, this is very strange.
>>
>> What type of hardware are you running on? Is it an A57-based chip or
>> something else? Also, what's your simulation quantum? I have been able to
>> run with a 0.5ms quantum  (5e8 ticks).
>> I think the following trace of two CPUs running in KVM should be roughly
>> equivalent to the trace you shared earlier. It was generated on a
>> commercially available 8xA57 (16GiB ram) using the following command (gem5
>> rev 9dc44b417):
>>
>> gem5.opt -r --debug-flags Kvm,KvmIO,KvmRun 
>> configs/example/arm/fs_bigLITTLE.py \
>> --sim-quantum '0.5ms' \
>> --cpu-type kvm --big-cpus 0 --little-cpus 2 \
>> --dtb system/arm/dt/armv8_gem5_v1_2cpu.dtb --kernel 
>> vmlinux.aarch64.4.4-d318f95d0c
>>
>> Note that the tick counts are a bit weird since we have three different
>> event queues at play (1 for devices and one per CPU).
>>
>>   0: system.littleCluster.cpus0: KVM: Executing for 5 ticks
>>   0: system.littleCluster.cpus1: KVM: Executing for 5 ticks
>>   0: system.littleCluster.cpus0: KVM: Executed 79170 instructions in 
>> 176363 cycles (88181504 ticks, sim cycles: 176363).
>> 88182000: system.littleCluster.cpus0: handleKvmExit (exit_reason: 6)
>> 88182000: system.littleCluster.cpus0: KVM: Handling MMIO (w: 1, addr: 
>> 0x1c090024, len: 4)
>> 88332000: system.littleCluster.cpus0: Entering KVM...
>> 88332000: system.littleCluster.cpus0: KVM: Executing for 411668000 ticks
>> 88332000: system.littleCluster.cpus0: KVM: Executed 4384 instructions in 
>> 16854 cycles (8427000 ticks, sim cycles: 16854).
>> 96759000: system.littleCluster.cpus0: handleKvmExit (exit_reason: 6)
>> 96759000: system.littleCluster.cpus0: KVM: Handling MMIO (w: 1, addr: 
>> 0x1c090030, len: 4)
>>   0: system.littleCluster.cpus1: KVM: Executed 409368 instructions in 
>> 666400 cycles (33320 ticks, sim cycles: 666400).
>> 33320: system.littleCluster.cpus1: Entering KVM...
>> 33320: system.littleCluster.cpus1: KVM: Executing for 16680 ticks
>> 96909000: system.littleCluster.cpus0: Entering KVM...
>> 96909000: system.littleCluster.cpus0: KVM: Executing for 403091000 ticks
>> 96909000: system.littleCluster.cpus0: KVM: Executed 4384 instructions in 
>> 15257 cycles (7628500 ticks, sim cycles: 15257).
>> 104538000: system.littleCluster.cpus0: handleKvmExit (exit_reason: 6)
>> 104538000: system.littleCluster.cpus0: KVM: Handling MMIO (w: 1, addr: 
>> 0x1c0100a0, len: 4)
>> 33320: system.littleCluster.cpus1: KVM: Executed 47544 instructions in 
>> 200820 cycles (10041 ticks, sim cycles: 200820).
>> 43361: system.littleCluster.cpus1: Entering KVM...
>> 43361: system.littleCluster.cpus1: KVM: Executing for 6639 ticks
>> 104688000: system.littleCluster.cpus0: Entering KVM...
>> 104688000: system.littleCluster.cpus0: KVM: Executing for 395312000 ticks
>> 104688000: system.littleCluster.cpus0: KVM: Executed 4382 instructions in 
>> 14942 cycles (7471000 ticks, sim cycles: 14942).
>>
>> Comparing this trace to yours, I'd say that there the frequent KVM exits
>> look a bit suspicious. I would expect secondary CPUs to make very little
>> process while the main CPU initializes the system and starts the early boot
>> code.
>>
>> There area  couple of possibilities that might be causing issues:
>>
>> 1) There is some CPU ID weirdness that confuses the boot code and puts
>> both CPUs in the holding pen. This seems unlikely since there are some
>> writes to the UART.
>>
>> 2) Some device is incorrectly mapped to the CPU event queues and causes
>> frequent KVM exits. Have a look at _build_kvm in fs_bigLITTLE.py, it
>> doesn't use configs/common, so no need to tear your eyes out. ;) Do you map
>> event queues in the same way? It's mapping all simulated devices to one
>> event queue and the CPUs to private event queues. It's important to remap
>> CPU child devices to the device queue instead of the CPU queue. Failing to
>> do this will cause chaos, madness, and quite possibly result in Armageddon.
>>
>>

[gem5-dev] Change in public/gem5[master]: learning_gem5: Add a simple Ruby protocol

2018-03-20 Thread Jason Lowe-Power (Gerrit)


Hello Nikos Nikoleris, Bradford Beckmann,

I'd like you to reexamine a change. Please visit

https://gem5-review.googlesource.com/8942

to look at the new patch set (#3).

Change subject: learning_gem5: Add a simple Ruby protocol
..

learning_gem5: Add a simple Ruby protocol

Adds the MSI protocol from "A Primer on Memory Consistency and Cache
Coherence" by Daniel J. Sorin, Mark D. Hill, and David A. Wood.

This code follows Learning gem5 Part 3.
http://learning.gem5.org/book/part3/index.html

This is meant to be a simple, clean, example of how to make a Ruby
protocol.
Currently, it only works in SE mode.

The next changeset will contain the required configuration files.

Change-Id: If2cc53f5e6b9c6891749f929d872671615a2b4ab
Signed-off-by: Jason Lowe-Power 
---
A src/learning_gem5/part3/MSI-cache.sm
A src/learning_gem5/part3/MSI-dir.sm
A src/learning_gem5/part3/MSI-msg.sm
A src/learning_gem5/part3/MSI.slicc
A src/learning_gem5/part3/SConsopts
5 files changed, 1,518 insertions(+), 0 deletions(-)


--
To view, visit https://gem5-review.googlesource.com/8942
To unsubscribe, or for help writing mail filters, visit  
https://gem5-review.googlesource.com/settings


Gerrit-Project: public/gem5
Gerrit-Branch: master
Gerrit-Change-Id: If2cc53f5e6b9c6891749f929d872671615a2b4ab
Gerrit-Change-Number: 8942
Gerrit-PatchSet: 3
Gerrit-Owner: Jason Lowe-Power 
Gerrit-Reviewer: Bradford Beckmann 
Gerrit-Reviewer: Jason Lowe-Power 
Gerrit-Reviewer: Nikos Nikoleris 
Gerrit-CC: Sooraj Puthoor 
Gerrit-MessageType: newpatchset
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] Change in public/gem5[master]: arch-arm, configs: Treat the bootloader rom as cacheable memory

2018-03-20 Thread Nikos Nikoleris (Gerrit)

Nikos Nikoleris has submitted this change and it was merged. (  
https://gem5-review.googlesource.com/8741 )


Change subject: arch-arm, configs: Treat the bootloader rom as cacheable  
memory

..

arch-arm, configs: Treat the bootloader rom as cacheable memory

Prior to this changeset the bootloader rom (instantiated as a
SimpleMemory) in ruby Arm systems was treated as an IO device and it
was fronted by a DMA controller. This changeset moves the bootloader
rom and adds it to the system as another memory with a dedicated
directory controller.

Change-Id: I094fed031cdef7f77a939d94f948d967b349b7e0
Reviewed-by: Andreas Sandberg 
Reviewed-on: https://gem5-review.googlesource.com/8741
Reviewed-by: Jason Lowe-Power 
Maintainer: Jason Lowe-Power 
---
M configs/common/FSConfig.py
M configs/example/fs.py
M configs/ruby/GPU_RfO.py
M configs/ruby/GPU_VIPER.py
M configs/ruby/GPU_VIPER_Baseline.py
M configs/ruby/GPU_VIPER_Region.py
M configs/ruby/Garnet_standalone.py
M configs/ruby/MESI_Three_Level.py
M configs/ruby/MESI_Two_Level.py
M configs/ruby/MI_example.py
M configs/ruby/MOESI_AMD_Base.py
M configs/ruby/MOESI_CMP_directory.py
M configs/ruby/MOESI_CMP_token.py
M configs/ruby/MOESI_hammer.py
M configs/ruby/Ruby.py
M src/dev/arm/RealView.py
M tests/configs/base_config.py
17 files changed, 109 insertions(+), 59 deletions(-)

Approvals:
  Jason Lowe-Power: Looks good to me, approved; Looks good to me, approved



diff --git a/configs/common/FSConfig.py b/configs/common/FSConfig.py
index 42cfafe..17498c4 100644
--- a/configs/common/FSConfig.py
+++ b/configs/common/FSConfig.py
@@ -1,4 +1,4 @@
-# Copyright (c) 2010-2012, 2015-2017 ARM Limited
+# Copyright (c) 2010-2012, 2015-2018 ARM Limited
 # All rights reserved.
 #
 # The license below extends only to copyright in the software and shall
@@ -326,8 +326,10 @@
 # iobus, as gem5's membus is only used for initialization and
 # SST doesn't use it.  Attaching nvmem to iobus solves this issue.
 # During initialization, system_port -> membus -> iobus -> nvmem.
-if external_memory or ruby:
+if external_memory:
 self.realview.setupBootLoader(self.iobus,  self, binary)
+elif ruby:
+self.realview.setupBootLoader(None, self, binary)
 else:
 self.realview.setupBootLoader(self.membus, self, binary)
 self.gic_cpu_addr = self.realview.gic.cpu_addr
@@ -386,8 +388,6 @@
 elif ruby:
 self._dma_ports = [ ]
 self.realview.attachOnChipIO(self.iobus, dma_ports=self._dma_ports)
-# Force Ruby to treat the boot ROM as an IO device.
-self.realview.nvmem.in_addr_map = False
 self.realview.attachIO(self.iobus, dma_ports=self._dma_ports)
 else:
 self.realview.attachOnChipIO(self.membus, self.bridge)
diff --git a/configs/example/fs.py b/configs/example/fs.py
index 0f87e2b..4031fd0 100644
--- a/configs/example/fs.py
+++ b/configs/example/fs.py
@@ -152,8 +152,9 @@
 test_sys.kvm_vm = KvmVM()

 if options.ruby:
+bootmem = getattr(test_sys, 'bootmem', None)
 Ruby.create_system(options, True, test_sys, test_sys.iobus,
-   test_sys._dma_ports)
+   test_sys._dma_ports, bootmem)

 # Create a seperate clock domain for Ruby
 test_sys.ruby.clk_domain = SrcClockDomain(clock =  
options.ruby_clock,

diff --git a/configs/ruby/GPU_RfO.py b/configs/ruby/GPU_RfO.py
index 832ea44..3331ab2 100644
--- a/configs/ruby/GPU_RfO.py
+++ b/configs/ruby/GPU_RfO.py
@@ -427,7 +427,8 @@
 parser.add_option("--tcc-dir-factor", type='int', default=4,
   help="TCCdir size = factor *(TCPs + TCC)")

-def create_system(options, full_system, system, dma_devices, ruby_system):
+def create_system(options, full_system, system, dma_devices, bootmem,
+  ruby_system):
 if buildEnv['PROTOCOL'] != 'GPU_RfO':
 panic("This script requires the GPU_RfO protocol to be built.")

diff --git a/configs/ruby/GPU_VIPER.py b/configs/ruby/GPU_VIPER.py
index e4ba180..37136af 100644
--- a/configs/ruby/GPU_VIPER.py
+++ b/configs/ruby/GPU_VIPER.py
@@ -390,7 +390,8 @@
 parser.add_option("--noL1", action = "store_true", default = False,
   help = "bypassL1")

-def create_system(options, full_system, system, dma_devices, ruby_system):
+def create_system(options, full_system, system, dma_devices, bootmem,
+  ruby_system):
 if buildEnv['PROTOCOL'] != 'GPU_VIPER':
 panic("This script requires the GPU_VIPER protocol to be built.")

diff --git a/configs/ruby/GPU_VIPER_Baseline.py  
b/configs/ruby/GPU_VIPER_Baseline.py

index 978d4cc..ec56925 100644
--- a/configs/ruby/GPU_VIPER_Baseline.py
+++ b/configs/ruby/GPU_VIPER_Baseline.py
@@ -373,7 +373,8 @@
 parser.add_option("--noL2", action =

[gem5-dev] Change in public/gem5[master]: arch, arm: Fix implicit-fallthrough GCC warnings

2018-03-20 Thread Chun-Chen TK Hsu (Gerrit)

Chun-Chen TK Hsu has submitted this change and it was merged. (  
https://gem5-review.googlesource.com/9101 )


Change subject: arch, arm: Fix implicit-fallthrough GCC warnings
..

arch, arm: Fix implicit-fallthrough GCC warnings

GCC 7 generates spurious fallthrough warnings in nested switch blocks
where the inner switch block return.  There is already a GCC fix [1]
submitted for review but, until it is merged into GCC trunk, GEM5 will
not build with GCC 7 due to these fallthrough warnings.  This patch
silences the spurious fallthrough warnings by appending a M5_UNREACHABLE
statement in the outer switch cases.

Note there is another GEM5 patch [2] to fix other fallthrough warnings.

[1] https://gcc.gnu.org/ml/gcc-patches/2018-02/msg01105.html
[2] https://gem5-review.googlesource.com/c/public/gem5/+/8541

Change-Id: I97cd8bfa90a88e93cee60cf27a8c93611d11a242
Signed-off-by: Chun-Chen Hsu 
Reviewed-on: https://gem5-review.googlesource.com/9101
Reviewed-by: Giacomo Travaglini 
Maintainer: Giacomo Travaglini 
---
M src/arch/arm/isa/formats/aarch64.isa
M src/arch/isa_parser.py
2 files changed, 7 insertions(+), 2 deletions(-)

Approvals:
  Giacomo Travaglini: Looks good to me, approved; Looks good to me, approved



diff --git a/src/arch/arm/isa/formats/aarch64.isa  
b/src/arch/arm/isa/formats/aarch64.isa

index 1b9a86c..7752ba0 100644
--- a/src/arch/arm/isa/formats/aarch64.isa
+++ b/src/arch/arm/isa/formats/aarch64.isa
@@ -1897,6 +1897,7 @@
 return new Unknown64(machInst);
 }
 }
+M5_UNREACHABLE;
   case 0x1:
   {
 if (bits(machInst, 31) ||
@@ -2005,7 +2006,7 @@
 M5_UNREACHABLE;
 }
 }
-return new FailUnimplemented("Unhandled Case4", machInst);
+M5_UNREACHABLE;
 }
 }
 }};
diff --git a/src/arch/isa_parser.py b/src/arch/isa_parser.py
index 6817349..a65149f 100755
--- a/src/arch/isa_parser.py
+++ b/src/arch/isa_parser.py
@@ -1565,6 +1565,9 @@
 # decoder method - cannot be split
 file = 'decoder.cc'
 with self.open(file) as f:
+fn = 'base/compiler.hh'
+f.write('#include "%s"\n' % fn)
+
 fn = 'decoder-g.cc.inc'
 assert(fn in self.files)
 f.write('#include "%s"\n' % fn)
@@ -2206,7 +2209,8 @@
 codeObj = t[3]
 # just wrap the decoding code from the block as a case in the
 # outer switch statement.
-codeObj.wrap_decode_block('\n%s\n' % ''.join(case_list))
+codeObj.wrap_decode_block('\n%s\n' % ''.join(case_list),
+  'M5_UNREACHABLE;\n')
 codeObj.has_decode_default = (case_list == ['default:'])
 t[0] = codeObj


--
To view, visit https://gem5-review.googlesource.com/9101
To unsubscribe, or for help writing mail filters, visit  
https://gem5-review.googlesource.com/settings


Gerrit-Project: public/gem5
Gerrit-Branch: master
Gerrit-Change-Id: I97cd8bfa90a88e93cee60cf27a8c93611d11a242
Gerrit-Change-Number: 9101
Gerrit-PatchSet: 10
Gerrit-Owner: Chun-Chen TK Hsu 
Gerrit-Assignee: Giacomo Travaglini 
Gerrit-Reviewer: Andreas Sandberg 
Gerrit-Reviewer: Chun-Chen TK Hsu 
Gerrit-Reviewer: Gabe Black 
Gerrit-Reviewer: Giacomo Travaglini 
Gerrit-Reviewer: Jason Lowe-Power 
Gerrit-Reviewer: Nikos Nikoleris 
Gerrit-MessageType: merged
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] Change in public/gem5[master]: arch, arm: Fix implicit-fallthrough GCC warnings

2018-03-20 Thread Giacomo Travaglini (Gerrit)

Giacomo Travaglini has uploaded a new patch set (#9) to the change  
originally created by Chun-Chen TK Hsu. (  
https://gem5-review.googlesource.com/9101 )


Change subject: arch, arm: Fix implicit-fallthrough GCC warnings
..

arch, arm: Fix implicit-fallthrough GCC warnings

GCC 7 generates spurious fallthrough warnings in nested switch blocks
where the inner switch block return.  There is already a GCC fix [1]
submitted for review but, until it is merged into GCC trunk, GEM5 will
not build with GCC 7 due to these fallthrough warnings.  This patch
silences the spurious fallthrough warnings by appending a M5_UNREACHABLE
statement in the outer switch cases.

Note there is another GEM5 patch [2] to fix other fallthrough warnings.

[1] https://gcc.gnu.org/ml/gcc-patches/2018-02/msg01105.html
[2] https://gem5-review.googlesource.com/c/public/gem5/+/8541

Change-Id: I97cd8bfa90a88e93cee60cf27a8c93611d11a242
Signed-off-by: Chun-Chen Hsu 
---
M src/arch/arm/isa/formats/aarch64.isa
M src/arch/isa_parser.py
2 files changed, 7 insertions(+), 2 deletions(-)


--
To view, visit https://gem5-review.googlesource.com/9101
To unsubscribe, or for help writing mail filters, visit  
https://gem5-review.googlesource.com/settings


Gerrit-Project: public/gem5
Gerrit-Branch: master
Gerrit-Change-Id: I97cd8bfa90a88e93cee60cf27a8c93611d11a242
Gerrit-Change-Number: 9101
Gerrit-PatchSet: 9
Gerrit-Owner: Chun-Chen TK Hsu 
Gerrit-Assignee: Giacomo Travaglini 
Gerrit-Reviewer: Andreas Sandberg 
Gerrit-Reviewer: Chun-Chen TK Hsu 
Gerrit-Reviewer: Gabe Black 
Gerrit-Reviewer: Giacomo Travaglini 
Gerrit-Reviewer: Jason Lowe-Power 
Gerrit-Reviewer: Nikos Nikoleris 
Gerrit-MessageType: newpatchset
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] Change in public/gem5[master]: mem-cache: Move insertBlock functionality in FALRU

2018-03-20 Thread Daniel Carvalho (Gerrit)


Hello Jason Lowe-Power,

I'd like you to reexamine a change. Please visit

https://gem5-review.googlesource.com/8882

to look at the new patch set (#2).

Change subject: mem-cache: Move insertBlock functionality in FALRU
..

mem-cache: Move insertBlock functionality in FALRU

Block insertion is being done in the getCandidates function, while the
insertBlock function does not do anything.

Change-Id: Iadab9c1ea61519214f66fa24c4b91c4fc95604c0
---
M src/mem/cache/tags/fa_lru.cc
M src/mem/cache/tags/fa_lru.hh
2 files changed, 18 insertions(+), 17 deletions(-)


--
To view, visit https://gem5-review.googlesource.com/8882
To unsubscribe, or for help writing mail filters, visit  
https://gem5-review.googlesource.com/settings


Gerrit-Project: public/gem5
Gerrit-Branch: master
Gerrit-Change-Id: Iadab9c1ea61519214f66fa24c4b91c4fc95604c0
Gerrit-Change-Number: 8882
Gerrit-PatchSet: 2
Gerrit-Owner: Daniel Carvalho 
Gerrit-Reviewer: Jason Lowe-Power 
Gerrit-MessageType: newpatchset
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] Change in public/gem5[master]: mem-cache: Split array indexing and replacement policies.

2018-03-20 Thread Daniel Carvalho (Gerrit)


Hello Nikos Nikoleris, Andreas Sandberg,

I'd like you to reexamine a change. Please visit

https://gem5-review.googlesource.com/8501

to look at the new patch set (#14).

Change subject: mem-cache: Split array indexing and replacement policies.
..

mem-cache: Split array indexing and replacement policies.

Replacement policies (LRU, Random) are currently considered as array
indexing methods, but have completely different functionalities:

- Array indexers determine the possible locations for block allocation.
  This information is used to generate replacement candidates when
  conflicts happen.
- Replacement policies determine which of the replacement candidates
  should be evicted to make room for new allocations.

For this reason, they were split into different classes. Advantages:

- Easier and more straightforward to implement other replacement
  policies (RRIP, LFU, ARC, ...)
- Allow easier future implementation of cache organization schemes

As now we can't assure the use of sets, the previous way to create a
true LRU is not viable. Now a timestamp_bits parameter controls how
many bits are dedicated for the timestamp, and a true LRU can be
achieved through an infinite number of bits (although a few bits suffice
in practice).

Change-Id: I23750db121f1474d17831137e6ff618beb2b3eda
---
M configs/common/cores/arm/O3_ARM_v7a.py
M configs/common/cores/arm/ex5_LITTLE.py
M configs/common/cores/arm/ex5_big.py
M src/mem/cache/Cache.py
M src/mem/cache/base.cc
M src/mem/cache/blk.hh
M src/mem/cache/cache.cc
A src/mem/cache/replacement_policies/ReplacementPolicies.py
A src/mem/cache/replacement_policies/SConscript
A src/mem/cache/replacement_policies/base.cc
A src/mem/cache/replacement_policies/base.hh
A src/mem/cache/replacement_policies/lru_rp.cc
A src/mem/cache/replacement_policies/lru_rp.hh
A src/mem/cache/replacement_policies/random_rp.cc
A src/mem/cache/replacement_policies/random_rp.hh
M src/mem/cache/tags/SConscript
M src/mem/cache/tags/Tags.py
M src/mem/cache/tags/base.hh
M src/mem/cache/tags/base_set_assoc.cc
M src/mem/cache/tags/base_set_assoc.hh
M src/mem/cache/tags/fa_lru.cc
M src/mem/cache/tags/fa_lru.hh
D src/mem/cache/tags/lru.cc
D src/mem/cache/tags/lru.hh
D src/mem/cache/tags/random_repl.cc
D src/mem/cache/tags/random_repl.hh
26 files changed, 645 insertions(+), 441 deletions(-)


--
To view, visit https://gem5-review.googlesource.com/8501
To unsubscribe, or for help writing mail filters, visit  
https://gem5-review.googlesource.com/settings


Gerrit-Project: public/gem5
Gerrit-Branch: master
Gerrit-Change-Id: I23750db121f1474d17831137e6ff618beb2b3eda
Gerrit-Change-Number: 8501
Gerrit-PatchSet: 14
Gerrit-Owner: Daniel Carvalho 
Gerrit-Reviewer: Andreas Sandberg 
Gerrit-Reviewer: Daniel Carvalho 
Gerrit-Reviewer: Nikos Nikoleris 
Gerrit-CC: Jason Lowe-Power 
Gerrit-MessageType: newpatchset
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] Change in public/gem5[master]: mem-cache: Split array indexing and replacement policies.

2018-03-20 Thread Daniel Carvalho (Gerrit)


Hello Nikos Nikoleris, Andreas Sandberg,

I'd like you to reexamine a change. Please visit

https://gem5-review.googlesource.com/8501

to look at the new patch set (#13).

Change subject: mem-cache: Split array indexing and replacement policies.
..

mem-cache: Split array indexing and replacement policies.

Replacement policies (LRU, Random) are currently considered as array
indexing methods, but have completely different functionalities:

- Array indexers determine the possible locations for block allocation.
  This information is used to generate replacement candidates when
  conflicts happen.
- Replacement policies determine which of the replacement candidates
  should be evicted to make room for new allocations.

For this reason, they were split into different classes. Advantages:

- Easier and more straightforward to implement other replacement
  policies (RRIP, LFU, ARC, ...)
- Allow easier future implementation of cache organization schemes

As now we can't assure the use of sets, the previous way to create a
true LRU is not viable. Now a timestamp_bits parameter controls how
many bits are dedicated for the timestamp, and a true LRU can be
achieved through an infinite number of bits (although a few bits suffice
in practice).

Change-Id: I23750db121f1474d17831137e6ff618beb2b3eda
---
M configs/common/cores/arm/O3_ARM_v7a.py
M configs/common/cores/arm/ex5_LITTLE.py
M configs/common/cores/arm/ex5_big.py
M src/mem/cache/Cache.py
M src/mem/cache/base.cc
M src/mem/cache/blk.hh
M src/mem/cache/cache.cc
A src/mem/cache/replacement_policies/ReplacementPolicies.py
A src/mem/cache/replacement_policies/SConscript
A src/mem/cache/replacement_policies/base.cc
A src/mem/cache/replacement_policies/base.hh
A src/mem/cache/replacement_policies/lru_rp.cc
A src/mem/cache/replacement_policies/lru_rp.hh
A src/mem/cache/replacement_policies/random_rp.cc
A src/mem/cache/replacement_policies/random_rp.hh
M src/mem/cache/tags/SConscript
M src/mem/cache/tags/Tags.py
M src/mem/cache/tags/base.cc
M src/mem/cache/tags/base.hh
M src/mem/cache/tags/base_set_assoc.cc
M src/mem/cache/tags/base_set_assoc.hh
M src/mem/cache/tags/fa_lru.cc
M src/mem/cache/tags/fa_lru.hh
D src/mem/cache/tags/lru.cc
D src/mem/cache/tags/lru.hh
D src/mem/cache/tags/random_repl.cc
D src/mem/cache/tags/random_repl.hh
27 files changed, 652 insertions(+), 447 deletions(-)


--
To view, visit https://gem5-review.googlesource.com/8501
To unsubscribe, or for help writing mail filters, visit  
https://gem5-review.googlesource.com/settings


Gerrit-Project: public/gem5
Gerrit-Branch: master
Gerrit-Change-Id: I23750db121f1474d17831137e6ff618beb2b3eda
Gerrit-Change-Number: 8501
Gerrit-PatchSet: 13
Gerrit-Owner: Daniel Carvalho 
Gerrit-Reviewer: Andreas Sandberg 
Gerrit-Reviewer: Daniel Carvalho 
Gerrit-Reviewer: Nikos Nikoleris 
Gerrit-CC: Jason Lowe-Power 
Gerrit-MessageType: newpatchset
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] Change in public/gem5[master]: mem-cache: Create BRRIP replacement policy

2018-03-20 Thread Daniel Carvalho (Gerrit)


Hello Jason Lowe-Power, Nikos Nikoleris,

I'd like you to reexamine a change. Please visit

https://gem5-review.googlesource.com/8891

to look at the new patch set (#5).

Change subject: mem-cache: Create BRRIP replacement policy
..

mem-cache: Create BRRIP replacement policy

Implementation of a Bimodal Re-Reference Interval Prediction
replacement policy.

Change-Id: I25d4a59a60ef7ac496c66852e394fd6cbaf50912
---
M src/mem/cache/blk.hh
M src/mem/cache/replacement_policies/ReplacementPolicies.py
M src/mem/cache/replacement_policies/SConscript
A src/mem/cache/replacement_policies/brrip_rp.cc
A src/mem/cache/replacement_policies/brrip_rp.hh
5 files changed, 257 insertions(+), 0 deletions(-)


--
To view, visit https://gem5-review.googlesource.com/8891
To unsubscribe, or for help writing mail filters, visit  
https://gem5-review.googlesource.com/settings


Gerrit-Project: public/gem5
Gerrit-Branch: master
Gerrit-Change-Id: I25d4a59a60ef7ac496c66852e394fd6cbaf50912
Gerrit-Change-Number: 8891
Gerrit-PatchSet: 5
Gerrit-Owner: Daniel Carvalho 
Gerrit-Reviewer: Daniel Carvalho 
Gerrit-Reviewer: Jason Lowe-Power 
Gerrit-Reviewer: Nikos Nikoleris 
Gerrit-MessageType: newpatchset
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] Change in public/gem5[master]: mem-cache: Create RRIP Replacement Policy

2018-03-20 Thread Daniel Carvalho (Gerrit)


Hello Jason Lowe-Power,

I'd like you to reexamine a change. Please visit

https://gem5-review.googlesource.com/8981

to look at the new patch set (#5).

Change subject: mem-cache: Create RRIP Replacement Policy
..

mem-cache: Create RRIP Replacement Policy

Implementation of a Re-Reference Interval Prediction replacement
policy.

Change-Id: Iba716eb5df2bf2be156e765f889d94f6ad00c91b
---
M src/mem/cache/replacement_policies/ReplacementPolicies.py
1 file changed, 3 insertions(+), 0 deletions(-)


--
To view, visit https://gem5-review.googlesource.com/8981
To unsubscribe, or for help writing mail filters, visit  
https://gem5-review.googlesource.com/settings


Gerrit-Project: public/gem5
Gerrit-Branch: master
Gerrit-Change-Id: Iba716eb5df2bf2be156e765f889d94f6ad00c91b
Gerrit-Change-Number: 8981
Gerrit-PatchSet: 5
Gerrit-Owner: Daniel Carvalho 
Gerrit-Reviewer: Daniel Carvalho 
Gerrit-Reviewer: Jason Lowe-Power 
Gerrit-MessageType: newpatchset
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] Change in public/gem5[master]: mem-cache: Create NRU Replacement Policy

2018-03-20 Thread Daniel Carvalho (Gerrit)

Daniel Carvalho has uploaded a new patch set (#3). (  
https://gem5-review.googlesource.com/9001 )


Change subject: mem-cache: Create NRU Replacement Policy
..

mem-cache: Create NRU Replacement Policy

Implementation of a Not Recently Used replacement policy.

Change-Id: I24ab3a6f1db6dcb756b869cfebb5c4bc544170e8
---
M src/mem/cache/replacement_policies/ReplacementPolicies.py
1 file changed, 3 insertions(+), 0 deletions(-)


--
To view, visit https://gem5-review.googlesource.com/9001
To unsubscribe, or for help writing mail filters, visit  
https://gem5-review.googlesource.com/settings


Gerrit-Project: public/gem5
Gerrit-Branch: master
Gerrit-Change-Id: I24ab3a6f1db6dcb756b869cfebb5c4bc544170e8
Gerrit-Change-Number: 9001
Gerrit-PatchSet: 3
Gerrit-Owner: Daniel Carvalho 
Gerrit-Reviewer: Daniel Carvalho 
Gerrit-CC: Jason Lowe-Power 
Gerrit-CC: Nikos Nikoleris 
Gerrit-MessageType: newpatchset
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] Change in public/gem5[master]: mem-cache: Create BRRIP replacement policy

2018-03-20 Thread Daniel Carvalho (Gerrit)


Hello Jason Lowe-Power, Nikos Nikoleris,

I'd like you to reexamine a change. Please visit

https://gem5-review.googlesource.com/8891

to look at the new patch set (#4).

Change subject: mem-cache: Create BRRIP replacement policy
..

mem-cache: Create BRRIP replacement policy

Implementation of a Bimodal Re-Reference Interval Prediction
replacement policy.

Change-Id: I25d4a59a60ef7ac496c66852e394fd6cbaf50912
---
M src/mem/cache/blk.hh
M src/mem/cache/replacement_policies/ReplacementPolicies.py
M src/mem/cache/replacement_policies/SConscript
A src/mem/cache/replacement_policies/brrip_rp.cc
A src/mem/cache/replacement_policies/brrip_rp.hh
5 files changed, 247 insertions(+), 0 deletions(-)


--
To view, visit https://gem5-review.googlesource.com/8891
To unsubscribe, or for help writing mail filters, visit  
https://gem5-review.googlesource.com/settings


Gerrit-Project: public/gem5
Gerrit-Branch: master
Gerrit-Change-Id: I25d4a59a60ef7ac496c66852e394fd6cbaf50912
Gerrit-Change-Number: 8891
Gerrit-PatchSet: 4
Gerrit-Owner: Daniel Carvalho 
Gerrit-Reviewer: Daniel Carvalho 
Gerrit-Reviewer: Jason Lowe-Power 
Gerrit-Reviewer: Nikos Nikoleris 
Gerrit-MessageType: newpatchset
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] Cron <m5test@zizzer> /z/m5/regression/do-regression quick

2018-03-20 Thread Cron Daemon

* build/HSAIL_X86/tests/opt/quick/se/04.gpu/x86/linux/gpu-ruby-GPU_RfO: 
FAILED!
* 
build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64c/minor-timing: 
FAILED!
* build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64c/o3-timing: 
FAILED!
* 
build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64c/simple-timing-ruby:
 FAILED!
* 
build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64c/simple-atomic: 
FAILED!
* 
build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64c/simple-timing: 
FAILED!
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/minor-timing: CHANGED!
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/simple-timing: 
CHANGED!
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/o3-timing: CHANGED!
* build/ALPHA/tests/opt/quick/se/01.hello-2T-smt/alpha/linux/o3-timing-mt: 
CHANGED!
* 
build/ALPHA/tests/opt/quick/se/03.learning-gem5/alpha/linux/learning-gem5-p1-simple:
 CHANGED!
* 
build/ALPHA/tests/opt/quick/se/03.learning-gem5/alpha/linux/learning-gem5-p1-two-level:
 CHANGED!
* 
build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-atomic: 
CHANGED!
* 
build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-atomic-dual:
 CHANGED!
* 
build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-timing: 
CHANGED!
* 
build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-timing-dual:
 CHANGED!
* build/MIPS/tests/opt/quick/se/00.hello/mips/linux/o3-timing: CHANGED!
* build/MIPS/tests/opt/quick/se/00.hello/mips/linux/simple-timing: CHANGED!
* build/MIPS/tests/opt/quick/se/00.hello/mips/linux/simple-timing-ruby: 
CHANGED!
* 
build/MIPS/tests/opt/quick/se/03.learning-gem5/mips/linux/learning-gem5-p1-simple:
 CHANGED!
* 
build/MIPS/tests/opt/quick/se/03.learning-gem5/mips/linux/learning-gem5-p1-two-level:
 CHANGED!
* 
build/NULL_MOESI_hammer/tests/opt/quick/se/60.rubytest/null/none/rubytest-ruby-MOESI_hammer:
 CHANGED!
* 
build/NULL_MESI_Two_Level/tests/opt/quick/se/60.rubytest/null/none/rubytest-ruby-MESI_Two_Level:
 CHANGED!
* 
build/NULL_MOESI_CMP_directory/tests/opt/quick/se/60.rubytest/null/none/rubytest-ruby-MOESI_CMP_directory:
 CHANGED!
* 
build/NULL_MOESI_CMP_token/tests/opt/quick/se/60.rubytest/null/none/rubytest-ruby-MOESI_CMP_token:
 CHANGED!
* build/POWER/tests/opt/quick/se/00.hello/power/linux/o3-timing: CHANGED!
* build/SPARC/tests/opt/quick/se/00.hello/sparc/linux/simple-timing: 
CHANGED!
* build/SPARC/tests/opt/quick/se/02.insttest/sparc/linux/o3-timing: CHANGED!
* build/SPARC/tests/opt/quick/se/02.insttest/sparc/linux/simple-timing: 
CHANGED!
* 
build/SPARC/tests/opt/quick/se/03.learning-gem5/sparc/linux/learning-gem5-p1-simple:
 CHANGED!
* 
build/SPARC/tests/opt/quick/se/03.learning-gem5/sparc/linux/learning-gem5-p1-two-level:
 CHANGED!
* 
build/SPARC/tests/opt/quick/se/40.m5threads-test-atomic/sparc/linux/o3-timing-mp:
 CHANGED!
* 
build/SPARC/tests/opt/quick/se/40.m5threads-test-atomic/sparc/linux/simple-timing-mp:
 CHANGED!
* 
build/SPARC/tests/opt/quick/se/40.m5threads-test-atomic/sparc/linux/simple-atomic-mp:
 CHANGED!
* build/SPARC/tests/opt/quick/se/50.vortex/sparc/linux/simple-timing: 
CHANGED!
* build/SPARC/tests/opt/quick/se/70.twolf/sparc/linux/simple-timing: 
CHANGED!
* build/X86/tests/opt/quick/se/00.hello/x86/linux/o3-timing: CHANGED!
* build/X86/tests/opt/quick/se/00.hello/x86/linux/simple-atomic: CHANGED!
* build/X86/tests/opt/quick/se/00.hello/x86/linux/simple-timing: CHANGED!
* build/X86/tests/opt/quick/se/00.hello/x86/linux/simple-timing-ruby: 
CHANGED!
* 
build/X86/tests/opt/quick/se/03.learning-gem5/x86/linux/learning-gem5-p1-two-level:
 CHANGED!
* 
build/X86/tests/opt/quick/se/03.learning-gem5/x86/linux/learning-gem5-p1-simple:
 CHANGED!
* build/X86/tests/opt/quick/se/10.mcf/x86/linux/simple-atomic: CHANGED!
* build/X86/tests/opt/quick/se/70.twolf/x86/linux/simple-atomic: CHANGED!
* build/X86/tests/opt/quick/se/70.twolf/x86/linux/simple-timing: CHANGED!
*** diff[simerr]: SKIPPED* 
build/ARM/tests/opt/quick/se/00.hello/arm/linux/o3-timing: CHANGED!Statistics 
mismatch
*** diff[simout]: SKIPPED* 
build/ARM/tests/opt/quick/se/00.hello/arm/linux/minor-timing: CHANGED!
* build/ARM/tests/opt/quick/se/00.hello/arm/linux/o3-timing-checker: 
CHANGED!
* build/ARM/tests/opt/quick/se/00.hello/arm/linux/simple-atomic: 
CHANGED!*** gem5: OK
* 
build/ARM/tests/opt/quick/se/00.hello/arm/linux/simple-atomic-dummychecker: 
CHANGED!
* build/ARM/tests/opt/quick/se/00.hello/arm/linux/simple-timing: CHANGED!
* 
build/ARM/tests/opt/quick/se/03.learning-gem5/arm/linux/learning-gem5-p1-simple:
 CHANGED!
* 
build/ARM/tests/opt/quick/se/03.learning-gem5/arm/linux/learning-gem5-p1-two-level:
 CHANGED!
Statistics mismatch* 
build/ARM/tests/opt/quick/se/10.mcf/arm/linux/simple-atomic:

Re: [gem5-dev] Multicore ARM v8 KVM based simulation

Re: [gem5-dev] Multicore ARM v8 KVM based simulation

[gem5-dev] Change in public/gem5[master]: learning_gem5: Add a simple Ruby protocol

[gem5-dev] Change in public/gem5[master]: arch-arm, configs: Treat the bootloader rom as cacheable memory

[gem5-dev] Change in public/gem5[master]: arch, arm: Fix implicit-fallthrough GCC warnings

[gem5-dev] Change in public/gem5[master]: arch, arm: Fix implicit-fallthrough GCC warnings

[gem5-dev] Change in public/gem5[master]: mem-cache: Move insertBlock functionality in FALRU

[gem5-dev] Change in public/gem5[master]: mem-cache: Split array indexing and replacement policies.

[gem5-dev] Change in public/gem5[master]: mem-cache: Split array indexing and replacement policies.

[gem5-dev] Change in public/gem5[master]: mem-cache: Create BRRIP replacement policy

[gem5-dev] Change in public/gem5[master]: mem-cache: Create RRIP Replacement Policy

[gem5-dev] Change in public/gem5[master]: mem-cache: Create NRU Replacement Policy

[gem5-dev] Change in public/gem5[master]: mem-cache: Create BRRIP replacement policy

[gem5-dev] Cron <m5test@zizzer> /z/m5/regression/do-regression quick

14 matches

Site Navigation

Mail list logo

Footer information