[gem5-dev] Change in gem5/gem5[master]: mem-cache: implementation of AMO policy framework and in_mem policy. ...
Hello Andreas Sandberg, Ciro Santilli, Giacomo Travaglini, Nikos Nikoleris, I'd like you to reexamine a change. Please visit https://gem5-review.googlesource.com/c/public/gem5/+/20208 to look at the new patch set (#4). Change subject: mem-cache: implementation of AMO policy framework and in_mem policy. Implementation of a framework that allows to create different policy configurations. For this example we implemented a memory only configuration where if the page is located in cache is invalidated and move the request to the next level. We implemented a naive policy that handles the amo operation in the first memory level its is a hit. .. mem-cache: implementation of AMO policy framework and in_mem policy. Implementation of a framework that allows to create different policy configurations. For this example we implemented a memory only configuration where if the page is located in cache is invalidated and move the request to the next level. We implemented a naive policy that handles the amo operation in the first memory level its is a hit. Change-Id: I2da1485a05f090267ea3cdf3d4d08a9d2be9296c --- M src/mem/cache/Cache.py A src/mem/cache/amo_policy/AmoPolicy.py A src/mem/cache/amo_policy/SConscript A src/mem/cache/amo_policy/base.hh A src/mem/cache/amo_policy/in_mem.cc A src/mem/cache/amo_policy/in_mem.hh A src/mem/cache/amo_policy/naive.cc A src/mem/cache/amo_policy/naive.hh M src/mem/cache/base.cc M src/mem/cache/base.hh 10 files changed, 451 insertions(+), 3 deletions(-) -- To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/20208 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: I2da1485a05f090267ea3cdf3d4d08a9d2be9296c Gerrit-Change-Number: 20208 Gerrit-PatchSet: 4 Gerrit-Owner: Jordi Vaquero Gerrit-Reviewer: Andreas Sandberg Gerrit-Reviewer: Ciro Santilli Gerrit-Reviewer: Giacomo Travaglini Gerrit-Reviewer: Jordi Vaquero Gerrit-Reviewer: Nikos Nikoleris Gerrit-CC: Daniel Carvalho Gerrit-CC: Jason Lowe-Power Gerrit-MessageType: newpatchset ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Largely removing the getPort function
This should be completely backwards compatible, even with noncoforming names. The new version of the default getPort won't be able to handle them, but it will just complain and then ignore them. You can always override getPort yourself and handle any names you don't want to pass down to the default implementation. Since the default used to just be to print an error and die, nobody should be depending on it doing anything non-fatal. With the change Andreas is suggesting (absorbing the name() + ".foo" into the Port constructor), then the semantics of things would change and you'd have to update. I'm generally in favor of that change, but since it breaks compatibility I'd want to treat it separately. Also, MemObjects are historical baggage now and don't do anything other than provide backwards compatibility. The only thing they used to do was host the getPort function, but now that that belongs to SimObject the MemObject doesn't really need to exist. Gabe On Tue, Sep 3, 2019 at 4:39 PM Jason Lowe-Power wrote: > Hi Gabe, > > I like the idea of this change. Getting rid of that silly getPort > boilerplate is really nice! > > I've looked through the changes, but maybe because it's late in the day, I > can't figure out how backwards compatible this change is. If I have my own > MemObject that's not in the mainline, will I need to make changes or will > everything "just work" (assuming I don't have non-conforming names)? If > it's *not* backwards compatible, then I suggest keeping the old interface > as well, if possible. > > Cheers, > Jason > > On Tue, Sep 3, 2019 at 2:33 AM Gabe Black wrote: > > > Another reason I'm treating the getPort part of things as an RFC is that > it > > is nice to have the flexibility of getPort, and I don't want to try to > > envision every possible way getPort could useful be used and make a > > dodad which will provide that specific functionality. For instance, I > could > > make something that would know how to forward ports in C++, or allow port > > aliases, but would that be any easier to use than just writing a little > > function to do it on the spot? Not having to do that in most simple cases > > is nice, being able to do it is nice, but having a hodge podge of doing > it > > manually and not is a little off putting... > > > > Gabe > > > > On Tue, Sep 3, 2019 at 2:26 AM Gabe Black wrote: > > > > > Hi folks. I was looking at creating a base Interrupts class which would > > be > > > ISA agnostic, and noticed that the x86 version inherited from > > > BasicPioDevice. If I wanted to maintain its functionality, I would need > > to > > > either make the base Interrupts class also inherit from BasicPioDevice, > > or > > > to reimplement that functionality directly in the x86 Interrupts > object. > > > > > > That didn't seem great. I thought about it a bit, and as a first step > > > decided to try templatizing PioPort so that it would be easier to use > > > without a PioDevice to go with it, complicating the inheritance > > hierarchy. > > > > > > https://gem5-review.googlesource.com/c/public/gem5/+/20568 > > > > > > That worked out well, but then I noticed that I'd have to write some > > goopy > > > boilerplate code to make the port work which BasicPioDevice took care > of. > > > It occurred to me that it would be possible to make ports register > > > themselves with a SimObject and then have the SimObject know to return > > them > > > in a default getPort implementation. That way the object hosting them > > > wouldn't have to do much more than just instantiate them with > parameters > > it > > > already needed to give them (more or less), and it would take care of > > > itself. > > > > > > That seems to also have mostly worked, although it touches a lot of > files > > > and I've only had time to do some very minimal testing (x86 hello world > > and > > > initial Linux boot). There are some places where getPort was doing > > > something more than the most basic, and those were left alone. > > > > > > https://gem5-review.googlesource.com/c/public/gem5/+/20572/1 > > > > > > One nice side effect of this effort is that it identified places where > > > ports were named using an inconsistent scheme (name() + "-foo" or just > > > "foo" instead of name() + ".foo"), or were not named the same thing in > > > python as they were in C++. > > > > > > Since this is a large change that only partially eliminates getPort, I > > > thought I'd treat this as an RFC for now and see what people think. > > > > > > A couple things I'm thinking of to improve the implementation is to > make > > > the PortNameMap more of a separate class than a map and a collection of > > > functions. That will make it easier to use in other places like in > > systemc > > > objects which have a parallel but independent mechanism in C++. > > > > > > I'm also thinking of setting up a Port forwarding mechanism in python > > > where you could say something like: > > > > > > class Foo(SimObject): > > > port =
Re: [gem5-dev] Largely removing the getPort function
Hi Gabe, I like the idea of this change. Getting rid of that silly getPort boilerplate is really nice! I've looked through the changes, but maybe because it's late in the day, I can't figure out how backwards compatible this change is. If I have my own MemObject that's not in the mainline, will I need to make changes or will everything "just work" (assuming I don't have non-conforming names)? If it's *not* backwards compatible, then I suggest keeping the old interface as well, if possible. Cheers, Jason On Tue, Sep 3, 2019 at 2:33 AM Gabe Black wrote: > Another reason I'm treating the getPort part of things as an RFC is that it > is nice to have the flexibility of getPort, and I don't want to try to > envision every possible way getPort could useful be used and make a > dodad which will provide that specific functionality. For instance, I could > make something that would know how to forward ports in C++, or allow port > aliases, but would that be any easier to use than just writing a little > function to do it on the spot? Not having to do that in most simple cases > is nice, being able to do it is nice, but having a hodge podge of doing it > manually and not is a little off putting... > > Gabe > > On Tue, Sep 3, 2019 at 2:26 AM Gabe Black wrote: > > > Hi folks. I was looking at creating a base Interrupts class which would > be > > ISA agnostic, and noticed that the x86 version inherited from > > BasicPioDevice. If I wanted to maintain its functionality, I would need > to > > either make the base Interrupts class also inherit from BasicPioDevice, > or > > to reimplement that functionality directly in the x86 Interrupts object. > > > > That didn't seem great. I thought about it a bit, and as a first step > > decided to try templatizing PioPort so that it would be easier to use > > without a PioDevice to go with it, complicating the inheritance > hierarchy. > > > > https://gem5-review.googlesource.com/c/public/gem5/+/20568 > > > > That worked out well, but then I noticed that I'd have to write some > goopy > > boilerplate code to make the port work which BasicPioDevice took care of. > > It occurred to me that it would be possible to make ports register > > themselves with a SimObject and then have the SimObject know to return > them > > in a default getPort implementation. That way the object hosting them > > wouldn't have to do much more than just instantiate them with parameters > it > > already needed to give them (more or less), and it would take care of > > itself. > > > > That seems to also have mostly worked, although it touches a lot of files > > and I've only had time to do some very minimal testing (x86 hello world > and > > initial Linux boot). There are some places where getPort was doing > > something more than the most basic, and those were left alone. > > > > https://gem5-review.googlesource.com/c/public/gem5/+/20572/1 > > > > One nice side effect of this effort is that it identified places where > > ports were named using an inconsistent scheme (name() + "-foo" or just > > "foo" instead of name() + ".foo"), or were not named the same thing in > > python as they were in C++. > > > > Since this is a large change that only partially eliminates getPort, I > > thought I'd treat this as an RFC for now and see what people think. > > > > A couple things I'm thinking of to improve the implementation is to make > > the PortNameMap more of a separate class than a map and a collection of > > functions. That will make it easier to use in other places like in > systemc > > objects which have a parallel but independent mechanism in C++. > > > > I'm also thinking of setting up a Port forwarding mechanism in python > > where you could say something like: > > > > class Foo(SimObject): > > port = ForwardPort(other_object's_port) > > > > And then when binding happened, it would go grab that other port from the > > other object and not try to get it from Foo. That won't help when ports > are > > forwarded to internal C++ objects which actually own the ports, but it > > would help if, for instance, you wanted to create a SubSystem which > wrapped > > some objects and wanted to poke some of the internal ports out for people > > to connect to. > > > > I'm also thinking about making some sort of container for vector ports > > which would also take care of registering with the SimObject so you don't > > have those clunky explicit addVectorPort calls lying around. > > > > Gabe > > > ___ > gem5-dev mailing list > gem5-dev@gem5.org > http://m5sim.org/mailman/listinfo/gem5-dev ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Change in gem5/gem5[master]: ruby: Fix the way stall map size is checked for availability
Srikant Bharadwaj has submitted this change. (
https://gem5-review.googlesource.com/c/public/gem5/+/20389 )
Change subject: ruby: Fix the way stall map size is checked for availability
..
ruby: Fix the way stall map size is checked for availability
To ensure that enqueuer observes the practical availability. We
check the message buffer queue size at the start of the cycle.
We also add the size of the stall queue to consider the total
queue size. However, messages can be moved from regular queue
to stall map. This leads to messages being considered twice leading
to false flow control. This patch fixes it by storing the stall map
size at the beginning of the cycle and considering it for checking
availability.
Change-Id: I6ea94f34fe5279b91f74e106d43263e55ec4bf06
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/20389
Maintainer: Jason Lowe-Power
Tested-by: kokoro
Reviewed-by: Jason Lowe-Power
---
M src/mem/ruby/network/MessageBuffer.cc
M src/mem/ruby/network/MessageBuffer.hh
2 files changed, 13 insertions(+), 3 deletions(-)
Approvals:
Jason Lowe-Power: Looks good to me, approved; Looks good to me, approved
kokoro: Regressions pass
diff --git a/src/mem/ruby/network/MessageBuffer.cc
b/src/mem/ruby/network/MessageBuffer.cc
index 03d1bb0..f8cab3c 100644
--- a/src/mem/ruby/network/MessageBuffer.cc
+++ b/src/mem/ruby/network/MessageBuffer.cc
@@ -51,6 +51,7 @@
m_consumer = NULL;
m_size_last_time_size_checked = 0;
m_size_at_cycle_start = 0;
+m_stalled_at_cycle_start = 0;
m_msgs_this_cycle = 0;
m_priority_rank = 0;
@@ -89,10 +90,12 @@
// until schd cycle, but enqueue operations effect the visible
// size immediately
unsigned int current_size = 0;
+unsigned int current_stall_size = 0;
if (m_time_last_time_pop < current_time) {
-// no pops this cycle - heap size is correct
+// no pops this cycle - heap and stall queue size is correct
current_size = m_prio_heap.size();
+current_stall_size = m_stall_map_size;
} else {
if (m_time_last_time_enqueue < current_time) {
// no enqueues this cycle - m_size_at_cycle_start is correct
@@ -102,15 +105,19 @@
// enqueued msgs to m_size_at_cycle_start
current_size = m_size_at_cycle_start + m_msgs_this_cycle;
}
+
+// Stall queue size at start is considered
+current_stall_size = m_stalled_at_cycle_start;
}
// now compare the new size with our max size
-if (current_size + m_stall_map_size + n <= m_max_size) {
+if (current_size + current_stall_size + n <= m_max_size) {
return true;
} else {
DPRINTF(RubyQueue, "n: %d, current_size: %d, heap size: %d, "
"m_max_size: %d\n",
-n, current_size, m_prio_heap.size(), m_max_size);
+n, current_size + current_stall_size,
+m_prio_heap.size(), m_max_size);
m_not_avail_count++;
return false;
}
@@ -234,6 +241,7 @@
// adjusted until schd cycle
if (m_time_last_time_pop < current_time) {
m_size_at_cycle_start = m_prio_heap.size();
+m_stalled_at_cycle_start = m_stall_map_size;
m_time_last_time_pop = current_time;
}
@@ -274,6 +282,7 @@
m_time_last_time_enqueue = 0;
m_time_last_time_pop = 0;
m_size_at_cycle_start = 0;
+m_stalled_at_cycle_start = 0;
m_msgs_this_cycle = 0;
}
diff --git a/src/mem/ruby/network/MessageBuffer.hh
b/src/mem/ruby/network/MessageBuffer.hh
index 05821d5..f92d565 100644
--- a/src/mem/ruby/network/MessageBuffer.hh
+++ b/src/mem/ruby/network/MessageBuffer.hh
@@ -192,6 +192,7 @@
Tick m_last_arrival_time;
unsigned int m_size_at_cycle_start;
+unsigned int m_stalled_at_cycle_start;
unsigned int m_msgs_this_cycle;
Stats::Scalar m_not_avail_count; // count the # of times I didn't
have N
--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/20389
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: I6ea94f34fe5279b91f74e106d43263e55ec4bf06
Gerrit-Change-Number: 20389
Gerrit-PatchSet: 2
Gerrit-Owner: Srikant Bharadwaj
Gerrit-Reviewer: Anthony Gutierrez
Gerrit-Reviewer: Gabe Black
Gerrit-Reviewer: Jason Lowe-Power
Gerrit-Reviewer: Jieming Yin
Gerrit-Reviewer: Matthew Poremba
Gerrit-Reviewer: Srikant Bharadwaj
Gerrit-Reviewer: kokoro
Gerrit-MessageType: merged
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Largely removing the getPort function
Another reason I'm treating the getPort part of things as an RFC is that it is nice to have the flexibility of getPort, and I don't want to try to envision every possible way getPort could useful be used and make a dodad which will provide that specific functionality. For instance, I could make something that would know how to forward ports in C++, or allow port aliases, but would that be any easier to use than just writing a little function to do it on the spot? Not having to do that in most simple cases is nice, being able to do it is nice, but having a hodge podge of doing it manually and not is a little off putting... Gabe On Tue, Sep 3, 2019 at 2:26 AM Gabe Black wrote: > Hi folks. I was looking at creating a base Interrupts class which would be > ISA agnostic, and noticed that the x86 version inherited from > BasicPioDevice. If I wanted to maintain its functionality, I would need to > either make the base Interrupts class also inherit from BasicPioDevice, or > to reimplement that functionality directly in the x86 Interrupts object. > > That didn't seem great. I thought about it a bit, and as a first step > decided to try templatizing PioPort so that it would be easier to use > without a PioDevice to go with it, complicating the inheritance hierarchy. > > https://gem5-review.googlesource.com/c/public/gem5/+/20568 > > That worked out well, but then I noticed that I'd have to write some goopy > boilerplate code to make the port work which BasicPioDevice took care of. > It occurred to me that it would be possible to make ports register > themselves with a SimObject and then have the SimObject know to return them > in a default getPort implementation. That way the object hosting them > wouldn't have to do much more than just instantiate them with parameters it > already needed to give them (more or less), and it would take care of > itself. > > That seems to also have mostly worked, although it touches a lot of files > and I've only had time to do some very minimal testing (x86 hello world and > initial Linux boot). There are some places where getPort was doing > something more than the most basic, and those were left alone. > > https://gem5-review.googlesource.com/c/public/gem5/+/20572/1 > > One nice side effect of this effort is that it identified places where > ports were named using an inconsistent scheme (name() + "-foo" or just > "foo" instead of name() + ".foo"), or were not named the same thing in > python as they were in C++. > > Since this is a large change that only partially eliminates getPort, I > thought I'd treat this as an RFC for now and see what people think. > > A couple things I'm thinking of to improve the implementation is to make > the PortNameMap more of a separate class than a map and a collection of > functions. That will make it easier to use in other places like in systemc > objects which have a parallel but independent mechanism in C++. > > I'm also thinking of setting up a Port forwarding mechanism in python > where you could say something like: > > class Foo(SimObject): > port = ForwardPort(other_object's_port) > > And then when binding happened, it would go grab that other port from the > other object and not try to get it from Foo. That won't help when ports are > forwarded to internal C++ objects which actually own the ports, but it > would help if, for instance, you wanted to create a SubSystem which wrapped > some objects and wanted to poke some of the internal ports out for people > to connect to. > > I'm also thinking about making some sort of container for vector ports > which would also take care of registering with the SimObject so you don't > have those clunky explicit addVectorPort calls lying around. > > Gabe > ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Largely removing the getPort function
Hi folks. I was looking at creating a base Interrupts class which would be ISA agnostic, and noticed that the x86 version inherited from BasicPioDevice. If I wanted to maintain its functionality, I would need to either make the base Interrupts class also inherit from BasicPioDevice, or to reimplement that functionality directly in the x86 Interrupts object. That didn't seem great. I thought about it a bit, and as a first step decided to try templatizing PioPort so that it would be easier to use without a PioDevice to go with it, complicating the inheritance hierarchy. https://gem5-review.googlesource.com/c/public/gem5/+/20568 That worked out well, but then I noticed that I'd have to write some goopy boilerplate code to make the port work which BasicPioDevice took care of. It occurred to me that it would be possible to make ports register themselves with a SimObject and then have the SimObject know to return them in a default getPort implementation. That way the object hosting them wouldn't have to do much more than just instantiate them with parameters it already needed to give them (more or less), and it would take care of itself. That seems to also have mostly worked, although it touches a lot of files and I've only had time to do some very minimal testing (x86 hello world and initial Linux boot). There are some places where getPort was doing something more than the most basic, and those were left alone. https://gem5-review.googlesource.com/c/public/gem5/+/20572/1 One nice side effect of this effort is that it identified places where ports were named using an inconsistent scheme (name() + "-foo" or just "foo" instead of name() + ".foo"), or were not named the same thing in python as they were in C++. Since this is a large change that only partially eliminates getPort, I thought I'd treat this as an RFC for now and see what people think. A couple things I'm thinking of to improve the implementation is to make the PortNameMap more of a separate class than a map and a collection of functions. That will make it easier to use in other places like in systemc objects which have a parallel but independent mechanism in C++. I'm also thinking of setting up a Port forwarding mechanism in python where you could say something like: class Foo(SimObject): port = ForwardPort(other_object's_port) And then when binding happened, it would go grab that other port from the other object and not try to get it from Foo. That won't help when ports are forwarded to internal C++ objects which actually own the ports, but it would help if, for instance, you wanted to create a SubSystem which wrapped some objects and wanted to poke some of the internal ports out for people to connect to. I'm also thinking about making some sort of container for vector ports which would also take care of registering with the SimObject so you don't have those clunky explicit addVectorPort calls lying around. Gabe ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Change in gem5/gem5[master]: sim: Set up a default getPort function in SimObject.
Gabe Black has uploaded a new patch set (#2). ( https://gem5-review.googlesource.com/c/public/gem5/+/20571 ) Change subject: sim: Set up a default getPort function in SimObject. .. sim: Set up a default getPort function in SimObject. Rather than have a custom written getPort for every class that needs Ports, we can maintain a map of names to Ports and vectors of Ports and then just look up ports that we need on demand. In the worst case this will require some small bit of code in each SimObject to register their ports, but practically speaking each Port will need a pointer to its parent Device, and should be able to register itself with the information it already has. This will make setting up ports on a SimObject more foolproof and automatic. The ports will just need to be declared in the python and C++ versions of the containing class, and most of the plumbing will take care of itself. Change-Id: Ide8eb074abf003a279f32bc65b40c8646ac3d493 --- M src/sim/sim_object.cc M src/sim/sim_object.hh 2 files changed, 68 insertions(+), 0 deletions(-) -- To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/20571 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: Ide8eb074abf003a279f32bc65b40c8646ac3d493 Gerrit-Change-Number: 20571 Gerrit-PatchSet: 2 Gerrit-Owner: Gabe Black Gerrit-MessageType: newpatchset ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Change in gem5/gem5[master]: arch, cpu, dev, mem, sim: Eliminate most of the getPort functions.
Gabe Black has uploaded this change for review. (
https://gem5-review.googlesource.com/c/public/gem5/+/20572 )
Change subject: arch,cpu,dev,mem,sim: Eliminate most of the getPort
functions.
..
arch,cpu,dev,mem,sim: Eliminate most of the getPort functions.
These functions are now largely redundant, with a few exceptions. Most
implementations of getPort just check against a list of strings and
return a port that has a matching name. This boilerplate just adds an
extra step to getting ports on an object up and running.
There are some objects which do complicated things with their ports,
like forward them to other objects, allocate them on the fly, allow
aliases, or just track them in a complex way. These are left alone
and can be addressed in a future CL if necessary.
Change-Id: I4ed6c5fb9c631ec2512416123fbc04145f38a9c0
---
M src/arch/x86/interrupts.hh
M src/arch/x86/pagetable_walker.cc
M src/arch/x86/pagetable_walker.hh
M src/cpu/base.cc
M src/cpu/base.hh
M src/cpu/testers/directedtest/RubyDirectedTester.cc
M src/cpu/testers/directedtest/RubyDirectedTester.hh
M src/cpu/testers/garnet_synthetic_traffic/GarnetSyntheticTraffic.cc
M src/cpu/testers/garnet_synthetic_traffic/GarnetSyntheticTraffic.hh
M src/cpu/testers/memtest/memtest.cc
M src/cpu/testers/memtest/memtest.hh
M src/cpu/testers/traffic_gen/base.cc
M src/cpu/testers/traffic_gen/base.hh
M src/dev/arm/gic_v3_its.cc
M src/dev/arm/gic_v3_its.hh
M src/dev/arm/smmu_v3.cc
M src/dev/arm/smmu_v3.hh
M src/dev/arm/smmu_v3_slaveifc.cc
M src/dev/arm/smmu_v3_slaveifc.hh
M src/dev/dma_device.cc
M src/dev/dma_device.hh
M src/dev/io_device.cc
M src/dev/io_device.hh
M src/dev/net/dist_etherlink.cc
M src/dev/net/dist_etherlink.hh
M src/dev/net/etherbus.cc
M src/dev/net/etherbus.hh
M src/dev/net/etherlink.cc
M src/dev/net/etherlink.hh
M src/dev/net/etherswitch.cc
M src/dev/net/etherswitch.hh
M src/dev/net/ethertap.cc
M src/dev/net/ethertap.hh
M src/dev/net/i8254xGBe.cc
M src/dev/net/i8254xGBe.hh
M src/dev/net/ns_gige.cc
M src/dev/net/ns_gige.hh
M src/dev/net/sinic.cc
M src/dev/net/sinic.hh
M src/dev/x86/i82094aa.cc
M src/dev/x86/i82094aa.hh
M src/gpu-compute/dispatcher.cc
M src/gpu-compute/dispatcher.hh
M src/gpu-compute/gpu_tlb.cc
M src/gpu-compute/gpu_tlb.hh
M src/gpu-compute/lds_state.cc
M src/gpu-compute/lds_state.hh
M src/gpu-compute/tlb_coalescer.cc
M src/gpu-compute/tlb_coalescer.hh
M src/learning_gem5/part2/simple_cache.cc
M src/learning_gem5/part2/simple_cache.hh
M src/learning_gem5/part2/simple_memobj.cc
M src/learning_gem5/part2/simple_memobj.hh
M src/mem/addr_mapper.cc
M src/mem/addr_mapper.hh
M src/mem/bridge.cc
M src/mem/bridge.hh
M src/mem/cache/base.cc
M src/mem/cache/base.hh
M src/mem/coherent_xbar.cc
M src/mem/comm_monitor.cc
M src/mem/comm_monitor.hh
M src/mem/dram_ctrl.cc
M src/mem/dram_ctrl.hh
M src/mem/dramsim2.cc
M src/mem/dramsim2.hh
M src/mem/mem_checker_monitor.cc
M src/mem/mem_delay.cc
M src/mem/mem_delay.hh
M src/mem/noncoherent_xbar.cc
M src/mem/qos/mem_sink.cc
M src/mem/qos/mem_sink.hh
M src/mem/ruby/slicc_interface/AbstractController.cc
M src/mem/ruby/slicc_interface/AbstractController.hh
M src/mem/ruby/system/RubyPort.cc
M src/mem/ruby/system/RubyPort.hh
M src/mem/serial_link.cc
M src/mem/serial_link.hh
M src/mem/simple_mem.cc
M src/mem/simple_mem.hh
M src/mem/xbar.cc
M src/sim/system.cc
M src/sim/system.hh
83 files changed, 75 insertions(+), 662 deletions(-)
diff --git a/src/arch/x86/interrupts.hh b/src/arch/x86/interrupts.hh
index dfdff2b..97e6c45 100644
--- a/src/arch/x86/interrupts.hh
+++ b/src/arch/x86/interrupts.hh
@@ -215,17 +215,6 @@
AddrRangeList getIntAddrRange() const override;
-Port (const std::string _name,
- PortID idx=InvalidPortID) override
-{
-if (if_name == "int_master") {
-return intMasterPort;
-} else if (if_name == "int_slave") {
-return intSlavePort;
-}
-return BasicPioDevice::getPort(if_name, idx);
-}
-
/*
* Functions to access and manipulate the APIC's registers.
*/
diff --git a/src/arch/x86/pagetable_walker.cc
b/src/arch/x86/pagetable_walker.cc
index 86f140f..b17c631 100644
--- a/src/arch/x86/pagetable_walker.cc
+++ b/src/arch/x86/pagetable_walker.cc
@@ -167,15 +167,6 @@
}
-Port &
-Walker::getPort(const std::string _name, PortID idx)
-{
-if (if_name == "port")
-return port;
-else
-return ClockedObject::getPort(if_name, idx);
-}
-
void
Walker::WalkerState::initState(ThreadContext * _tc,
BaseTLB::Mode _mode, bool _isTiming)
diff --git a/src/arch/x86/pagetable_walker.hh
b/src/arch/x86/pagetable_walker.hh
index 73e8924..8139504 100644
--- a/src/arch/x86/pagetable_walker.hh
+++ b/src/arch/x86/pagetable_walker.hh
@@ -163,8 +163,6 @@
const RequestPtr , BaseTLB::Mode mode);
Fault startFunctional(ThreadContext * _tc, Addr ,
unsigned , BaseTLB::Mode
[gem5-dev] Change in gem5/gem5[master]: sim: Add a SimObject *parent parameter to the Port constructor.
Gabe Black has uploaded this change for review. (
https://gem5-review.googlesource.com/c/public/gem5/+/20570 )
Change subject: sim: Add a SimObject *parent parameter to the Port
constructor.
..
sim: Add a SimObject *parent parameter to the Port constructor.
If this parameter is set and this port isn't part of a vector which
will handle its retrieval, then the port will register itself with the
parent SimObject so it will be automatically returned by getPort.
Change-Id: I0d2be9810b8a45b94438e499d44282a016eedd9b
---
M src/sim/port.cc
M src/sim/port.hh
2 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/src/sim/port.cc b/src/sim/port.cc
index fa7df18..1675da7 100644
--- a/src/sim/port.cc
+++ b/src/sim/port.cc
@@ -48,8 +48,14 @@
*/
#include "sim/port.hh"
+#include "sim/sim_object.hh"
-Port::Port(const std::string& _name, PortID _id) :
+Port::Port(const std::string &_name, PortID _id, SimObject *parent) :
portName(_name), id(_id), _peer(nullptr), _connected(false)
-{}
+{
+// If this port has a known parent and isn't part of a vector, tell the
+// parent to return it when asked.
+if (parent && _id == InvalidPortID)
+parent->addPort(_name, *this);
+}
Port::~Port() {}
diff --git a/src/sim/port.hh b/src/sim/port.hh
index 2acdb7a..c713055 100644
--- a/src/sim/port.hh
+++ b/src/sim/port.hh
@@ -54,6 +54,8 @@
#include "base/types.hh"
+class SimObject;
+
/**
* Ports are used to interface objects to each other.
*/
@@ -90,7 +92,7 @@
* @param _name Port name including the owners name
* @param _id A port identifier for vector ports
*/
-Port(const std::string& _name, PortID _id);
+Port(const std::string &_name, PortID _id, SimObject *parent=nullptr);
/**
* Virtual destructor due to inheritance.
--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/20570
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: I0d2be9810b8a45b94438e499d44282a016eedd9b
Gerrit-Change-Number: 20570
Gerrit-PatchSet: 1
Gerrit-Owner: Gabe Black
Gerrit-MessageType: newchange
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Change in gem5/gem5[master]: mem: Make MasterPort and SlavePort pass their _owner to Port.
Gabe Black has uploaded this change for review. (
https://gem5-review.googlesource.com/c/public/gem5/+/20569 )
Change subject: mem: Make MasterPort and SlavePort pass their _owner to
Port.
..
mem: Make MasterPort and SlavePort pass their _owner to Port.
This will make Port set them up in their parent SimObject so that they
will be returned by the default getPort implementation.
Change-Id: I34ab13ca8556f2022a0d3149930f5a683b88dfb7
---
M src/mem/port.cc
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mem/port.cc b/src/mem/port.cc
index 36e11ca..a0b83fb 100644
--- a/src/mem/port.cc
+++ b/src/mem/port.cc
@@ -55,7 +55,7 @@
* Master port
*/
MasterPort::MasterPort(const std::string& name, SimObject* _owner, PortID
_id)
-: Port(name, _id), _slavePort(NULL), owner(*_owner)
+: Port(name, _id, _owner), _slavePort(NULL), owner(*_owner)
{
}
@@ -112,7 +112,7 @@
* Slave port
*/
SlavePort::SlavePort(const std::string& name, SimObject* _owner, PortID id)
-: Port(name, id), _masterPort(NULL), defaultBackdoorWarned(false),
+: Port(name, id, _owner), _masterPort(NULL),
defaultBackdoorWarned(false),
owner(*_owner)
{
}
--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/20569
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: I34ab13ca8556f2022a0d3149930f5a683b88dfb7
Gerrit-Change-Number: 20569
Gerrit-PatchSet: 1
Gerrit-Owner: Gabe Black
Gerrit-MessageType: newchange
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Change in gem5/gem5[master]: sim: Set up a default getPort function in SimObject.
Gabe Black has uploaded this change for review. (
https://gem5-review.googlesource.com/c/public/gem5/+/20571 )
Change subject: sim: Set up a default getPort function in SimObject.
..
sim: Set up a default getPort function in SimObject.
Rather than have a custom written getPort for every class that needs
Ports, we can maintain a map of names to Ports and vectors of Ports
and then just look up ports that we need on demand.
In the worst case this will require some small bit of code in each
SimObject to register their ports, but practically speaking each Port
will need a pointer to its parent Device, and should be able to
register itself with the information it already has.
This will make setting up ports on a SimObject more foolproof and
automatic. The ports will just need to be declared in the python and
C++ versions of the containing class, and most of the plumbing will
take care of itself.
Change-Id: Ide8eb074abf003a279f32bc65b40c8646ac3d493
---
M src/sim/sim_object.cc
M src/sim/sim_object.hh
2 files changed, 68 insertions(+), 0 deletions(-)
diff --git a/src/sim/sim_object.cc b/src/sim/sim_object.cc
index 7b794a0..ad7901a 100644
--- a/src/sim/sim_object.cc
+++ b/src/sim/sim_object.cc
@@ -136,6 +136,10 @@
Port &
SimObject::getPort(const std::string _name, PortID idx)
{
+auto it = _portNameMap.find(if_name);
+if (it != _portNameMap.end())
+return it->second(idx);
+
fatal("%s does not have any port named %s\n", name(), if_name);
}
diff --git a/src/sim/sim_object.hh b/src/sim/sim_object.hh
index 5c9bf00..219ff60 100644
--- a/src/sim/sim_object.hh
+++ b/src/sim/sim_object.hh
@@ -107,6 +107,30 @@
/** Cached copy of the object parameters. */
const SimObjectParams *_params;
+/** Ports for the default getPort function to return. */
+typedef std::function PortGetterFunc;
+typedef std::map PortNameMap;
+PortNameMap _portNameMap;
+
+void
+addPortMapEntry(std::string port_name, PortGetterFunc func)
+{
+// Strip off the parent part of this ports name.
+std::string so_name = name();
+size_t so_name_len = so_name.length();
+if ((port_name.compare(0, so_name_len, so_name) ||
+ port_name.at(so_name_len) != '.')) {
+warn("Port name %s is malformed and won't be returned by "
+"SimObject::getPort.", port_name);
+return;
+}
+
+auto it_pair = _portNameMap.insert(
+{port_name.substr(so_name_len + 1), func});
+panic_if(!it_pair.second,
+"Port named %s already registered.\n", port_name);
+}
+
public:
typedef SimObjectParams Params;
const Params *params() const { return _params; }
@@ -115,6 +139,46 @@
public:
+void
+addPort(std::string name, Port )
+{
+auto port_getter = [](PortID idx) -> Port &
+{
+panic_if(idx != InvalidPortID, "Port %s is not a vector port.",
+ port.name());
+return port;
+};
+addPortMapEntry(name, port_getter);
+}
+
+template
+void
+addVectorPort(std::string name, std::vector )
+{
+auto port_getter = [, name](PortID idx) -> Port &
+{
+panic_if(idx >= ports.size(),
+"Port index %d is larger than %s (%d).",
+idx, name, ports.size());
+return ports[idx];
+};
+addPortMapEntry(name, port_getter);
+}
+
+template
+void
+addVectorPort(std::string name, std::vector )
+{
+auto port_getter = [, name](PortID idx) -> Port &
+{
+panic_if(idx >= ports.size(),
+"Port index %d is larger than %s (%d).",
+idx, name, ports.size());
+return *ports[idx];
+};
+addPortMapEntry(name, port_getter);
+}
+
virtual const std::string name() const { return params()->name; }
/**
--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/20571
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: Ide8eb074abf003a279f32bc65b40c8646ac3d493
Gerrit-Change-Number: 20571
Gerrit-PatchSet: 1
Gerrit-Owner: Gabe Black
Gerrit-MessageType: newchange
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Change in gem5/gem5[master]: dev: Templatize PioPort.
Gabe Black has uploaded this change for review. (
https://gem5-review.googlesource.com/c/public/gem5/+/20568 )
Change subject: dev: Templatize PioPort.
..
dev: Templatize PioPort.
When creating a base class which needs to be a SimObject, it's
necessary to decide ahead of time whether to use PioDevice or
BasicPioDevice in the hierarchy because they inherit from SimObject. If
they were added into the hierarchy later, then the original class would
inherit from SimObject, as would PioDevice. That would create a diamond
inheritance structure which would require virtual inheritance, and
that's a can of worms we'd rather not get into.
A big part of the PioPort mechanism is the PioPort itself which holds
a pointer to its parent device and delegates reads/writes to it. It
does that with a PioDevice pointer, and PioDevice declares virtual
functions for all the callbacks the port can call into.
Instead of that, this change templatizes PioPort based on the class of
the device that holds it. That will let you use a PioPort on *any*
class, as long as it has the methods PioPort depends on. That removes
the need to create an inheritance diamond to add a PioPort down the
line since PioDevice is no longer strictly required.
The PioDevice and BasicPioDevice classes are still around since they
still provide some additional functionality and there are existing
classes which depend on them.
Change-Id: I753afc1e0fa54b91217d54c1f8743c150537e960
---
M src/dev/io_device.cc
M src/dev/io_device.hh
2 files changed, 26 insertions(+), 33 deletions(-)
diff --git a/src/dev/io_device.cc b/src/dev/io_device.cc
index 425c2f4..64550ea 100644
--- a/src/dev/io_device.cc
+++ b/src/dev/io_device.cc
@@ -47,30 +47,6 @@
#include "debug/AddrRanges.hh"
#include "sim/system.hh"
-PioPort::PioPort(PioDevice *dev)
-: SimpleTimingPort(dev->name() + ".pio", dev), device(dev)
-{
-}
-
-Tick
-PioPort::recvAtomic(PacketPtr pkt)
-{
-// technically the packet only reaches us after the header delay,
-// and typically we also need to deserialise any payload
-Tick receive_delay = pkt->headerDelay + pkt->payloadDelay;
-pkt->headerDelay = pkt->payloadDelay = 0;
-
-const Tick delay(pkt->isRead() ? device->read(pkt) :
device->write(pkt));
-assert(pkt->isResponse() || pkt->isError());
-return delay + receive_delay;
-}
-
-AddrRangeList
-PioPort::getAddrRanges() const
-{
-return device->getAddrRanges();
-}
-
PioDevice::PioDevice(const Params *p)
: ClockedObject(p), sys(p->system), pioPort(this)
{}
diff --git a/src/dev/io_device.hh b/src/dev/io_device.hh
index c9e25d2..8041338 100644
--- a/src/dev/io_device.hh
+++ b/src/dev/io_device.hh
@@ -59,19 +59,37 @@
* must respond to. The device must also provide getAddrRanges() function
* with which it returns the address ranges it is interested in.
*/
+template
class PioPort : public SimpleTimingPort
{
protected:
/** The device that this port serves. */
-PioDevice *device;
+Device *device;
-virtual Tick recvAtomic(PacketPtr pkt);
+Tick
+recvAtomic(PacketPtr pkt) override
+{
+// Technically the packet only reaches us after the header delay,
+// and typically we also need to deserialise any payload.
+Tick receive_delay = pkt->headerDelay + pkt->payloadDelay;
+pkt->headerDelay = pkt->payloadDelay = 0;
-virtual AddrRangeList getAddrRanges() const;
+const Tick delay =
+pkt->isRead() ? device->read(pkt) : device->write(pkt);
+assert(pkt->isResponse() || pkt->isError());
+return delay + receive_delay;
+}
+
+AddrRangeList
+getAddrRanges() const override
+{
+return device->getAddrRanges();
+}
public:
-
-PioPort(PioDevice *dev);
+PioPort(Device *dev) :
+SimpleTimingPort(dev->name() + ".pio", dev), device(dev)
+{}
};
/**
@@ -88,7 +106,7 @@
/** The pioPort that handles the requests for us and provides us
requests
* that it sees. */
-PioPort pioPort;
+PioPort pioPort;
/**
* Every PIO device is obliged to provide an implementation that
@@ -128,7 +146,7 @@
Port (const std::string _name,
PortID idx=InvalidPortID) override;
-friend class PioPort;
+friend class PioPort;
};
@@ -159,8 +177,7 @@
*
* @return a list of non-overlapping address ranges
*/
-virtual AddrRangeList getAddrRanges() const;
-
+AddrRangeList getAddrRanges() const override;
};
#endif // __DEV_IO_DEVICE_HH__
--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/20568
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: I753afc1e0fa54b91217d54c1f8743c150537e960
Gerrit-Change-Number: 20568
Gerrit-PatchSet: 1
Gerrit-Owner: Gabe Black
Gerrit-MessageType:
[gem5-dev] Change in gem5/gem5[master]: configs: Fix replacement policy assignment
Daniel Carvalho has submitted this change. ( https://gem5-review.googlesource.com/c/public/gem5/+/20548 ) Change subject: configs: Fix replacement policy assignment .. configs: Fix replacement policy assignment Commit d207e9ccee411877fdeac80bb68a27900560f50f reworked the tags to split the replacement policies, however the name of the variable that contains the replacement policy changed between patch revisions, which was not updated accordingly in the configs files. Change-Id: I2072529e2c7d54197c371bcaa323bfd9f34ec3ba Signed-off-by: Daniel R. Carvalho Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/20548 Reviewed-by: Jason Lowe-Power Maintainer: Jason Lowe-Power Tested-by: kokoro --- 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 3 files changed, 3 insertions(+), 3 deletions(-) Approvals: Jason Lowe-Power: Looks good to me, approved; Looks good to me, approved kokoro: Regressions pass diff --git a/configs/common/cores/arm/O3_ARM_v7a.py b/configs/common/cores/arm/O3_ARM_v7a.py index 3a1f9af..ea3 100644 --- a/configs/common/cores/arm/O3_ARM_v7a.py +++ b/configs/common/cores/arm/O3_ARM_v7a.py @@ -204,4 +204,4 @@ # Simple stride prefetcher prefetcher = StridePrefetcher(degree=8, latency = 1) tags = BaseSetAssoc() -repl_policy = RandomRP() +replacement_policy = RandomRP() diff --git a/configs/common/cores/arm/ex5_LITTLE.py b/configs/common/cores/arm/ex5_LITTLE.py index 85fdd55..ab94666 100644 --- a/configs/common/cores/arm/ex5_LITTLE.py +++ b/configs/common/cores/arm/ex5_LITTLE.py @@ -149,4 +149,4 @@ # Simple stride prefetcher prefetcher = StridePrefetcher(degree=1, latency = 1) tags = BaseSetAssoc() -repl_policy = RandomRP() +replacement_policy = RandomRP() diff --git a/configs/common/cores/arm/ex5_big.py b/configs/common/cores/arm/ex5_big.py index 445aa32..c2b25a0 100644 --- a/configs/common/cores/arm/ex5_big.py +++ b/configs/common/cores/arm/ex5_big.py @@ -201,4 +201,4 @@ # Simple stride prefetcher prefetcher = StridePrefetcher(degree=8, latency = 1) tags = BaseSetAssoc() -repl_policy = RandomRP() +replacement_policy = RandomRP() -- To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/20548 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: I2072529e2c7d54197c371bcaa323bfd9f34ec3ba Gerrit-Change-Number: 20548 Gerrit-PatchSet: 2 Gerrit-Owner: Daniel Carvalho Gerrit-Reviewer: Daniel Carvalho Gerrit-Reviewer: Jason Lowe-Power Gerrit-Reviewer: kokoro Gerrit-MessageType: merged ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
