Re: [m5-dev] Restricting W-W reordering in O3
But I need to find the point to log order of completion of loads and stores in the LSQ (between LSQ and L1 cache), to check the effect of that change. I was observing inside LSQUnitImpl::completeDataAccess(PacketPtr pkt). But the order observed doesn't look like the expected. Looks like you are going to have to check the TSO (?) semantics here. Whose to say that if you issue a # of memory accesses in a particular order, that they finish in a particular order? Isn't caching (and locality of your memory accesses) going to determine this? Is it not OK that the memory accesses are sent to the memory system in a certain order but arent necessarily completed in a certain order? Again, you'll need to check the TSO or whatever constraints you are trying to enforce for that case. -- - Korey ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Restricting W-W reordering in O3
Korey,
That idea of creating a fault was probably leading to a dead lock, as you
stated. Then, trying to stall the access as suggested, I added constraints
between stores in the Instruction Queue (actually inside MemDepUnit), where
only membar constraints were handled before. The simulator executed without
problems.
Code in MemDepUnitMemDepPred, Impl::insert(DynInstPtr inst)
...
} else {
producing_store = depPred.checkInst(inst-instAddr());
}
if (inst-isStore() store) { // Add new constraint
if(producing_store == 0) {
producing_store = storeSN;
} else {
producing_store = (storeSN producing_store ? storeSN : producing_store);
}
}
...
But I need to find the point to log order of completion of loads and stores
in the LSQ (between LSQ and L1 cache), to check the effect of that change.
I was observing inside LSQUnitImpl::completeDataAccess(PacketPtr pkt).
But the order observed doesn't look like the expected.
I wonder if I'm observing the right place...
Thank you,
--
Eberle.
On Tue, Feb 1, 2011 at 3:31 AM, Korey Sewell ksew...@umich.edu wrote:
Are your changes:
1) Causing the simulator to assert/panic/not function correctly.
or
2) Allowing the simulator to work but giving you unexpected results (bad
stats, etc.?)
If #2, it's a bigger picture issue and you'll need to add some debug
statements in the code to make sure that stores are only seen in order (e.g.
print out the sequence number for the instruction before a store is sent)
If #1, you'll need to place some code blocking the store from going to the
memory system. At some point, the instructions dependent on the store you
just set to not executed will need the values from that store, so unless
you are setting the store to executed at some point then a deadlock sounds
like a probable issue.
But also, you need to find where there is a sendTiming call in the o3
model or whatever function/code is executing the store and not execute it
unless it's at the head of the queue. I havent looked at that code in
awhile, so that's probably the best advice I could give for now, but judging
from your last snippet, why would you need to create a fault if your store
ordering is violated rather than just stall that access from
initiating/executing/etc?
I would think that the O3 has a choice of instructions to choose from in
each IEW cycle, so why not just make the choice from the LSQ unavailable if
something is out of order? What's the correct thing in HW to do there?
Anyway, hope that helps...
On Fri, Jan 28, 2011 at 12:12 PM, Eberle rambo.u...@gmail.com wrote:
Steve, what about adding dependencies between stores in the Memory
Dependency Unit, should it do the trick or needs other modifications?
I've added the restrictions but the result wasn't the expected. Maybe I
need to make more changes in other places?
As I'm using SPARC, I'd need the processor to implement the TSO model, or
at least for now, to not allow reordering between stores.
Thanks in advance,
--
Eberle.
On Tue, Jan 25, 2011 at 1:25 PM, Eberle rambo.u...@gmail.com wrote:
Right, what I need is to prevent the reordering of stores. The stores
should be executed in program order, the oldest store must be executed
before a younger store is allowed to execute.
Using O3 cpu and SPARC_SE.
When the following code is put before 'store_inst-initiateAcc();'
in LSQUnitImpl::executeStore(..) :
if (store_idx != storeHead) {
memDepViolator = storeQueue[storeHead].inst;
++lsqMemOrderViolation;
return genMachineCheckFault();
}
The following happens:
M5 Simulator System
Copyright (c) 2001-2008
The Regents of The University of Michigan
All Rights Reserved
M5 compiled Jan 25 2011 12:47:37
M5 revision 4c0f7929ee33+ 7842+ default tip
M5 started Jan 25 2011 12:47:44
M5 executing on bellatrix
command line: ./build/SPARC_SE/m5.fast configs/teste.py -n 2 -b
Helloworld -d
Global frequency set at 1 ticks per second
0: system.remote_gdb.listener: listening for remote gdb on port 7000
0: system.remote_gdb.listener: listening for remote gdb on port 7001
info: Entering event queue @ 0. Starting simulation...
panic: Tried to access unmapped address 0x8.
@ cycle 9577000
[invoke:build/SPARC_SE/arch/sparc/faults.cc, line 654]
Memory Usage: 189360 KBytes
For more information see: http://www.m5sim.org/panic/5932f339
Program aborted at cycle 9577000
Aborted
In addition, I also tried not setting the store instruction as executed
when a reordering case is detected in DefaultIEWImpl::executeInsts() :
...
fault = ldstQueue.executeStore(inst);
if(ldstQueue.violation(inst-threadNumber)){
// Don't set as executed
activityThisCycle();
} else
And this happens:
M5 Simulator System
Copyright (c) 2001-2008
The Regents of The University of Michigan
All Rights Reserved
M5 compiled Jan 25 2011 13:21:18
M5 revision 4c0f7929ee33+ 7842+ default tip
M5 started Jan 25 2011
Re: [m5-dev] Restricting W-W reordering in O3
Are your changes:
1) Causing the simulator to assert/panic/not function correctly.
or
2) Allowing the simulator to work but giving you unexpected results (bad
stats, etc.?)
If #2, it's a bigger picture issue and you'll need to add some debug
statements in the code to make sure that stores are only seen in order (e.g.
print out the sequence number for the instruction before a store is sent)
If #1, you'll need to place some code blocking the store from going to the
memory system. At some point, the instructions dependent on the store you
just set to not executed will need the values from that store, so unless
you are setting the store to executed at some point then a deadlock sounds
like a probable issue.
But also, you need to find where there is a sendTiming call in the o3
model or whatever function/code is executing the store and not execute it
unless it's at the head of the queue. I havent looked at that code in
awhile, so that's probably the best advice I could give for now, but judging
from your last snippet, why would you need to create a fault if your store
ordering is violated rather than just stall that access from
initiating/executing/etc?
I would think that the O3 has a choice of instructions to choose from in
each IEW cycle, so why not just make the choice from the LSQ unavailable if
something is out of order? What's the correct thing in HW to do there?
Anyway, hope that helps...
On Fri, Jan 28, 2011 at 12:12 PM, Eberle rambo.u...@gmail.com wrote:
Steve, what about adding dependencies between stores in the Memory
Dependency Unit, should it do the trick or needs other modifications?
I've added the restrictions but the result wasn't the expected. Maybe I
need to make more changes in other places?
As I'm using SPARC, I'd need the processor to implement the TSO model, or
at least for now, to not allow reordering between stores.
Thanks in advance,
--
Eberle.
On Tue, Jan 25, 2011 at 1:25 PM, Eberle rambo.u...@gmail.com wrote:
Right, what I need is to prevent the reordering of stores. The stores
should be executed in program order, the oldest store must be executed
before a younger store is allowed to execute.
Using O3 cpu and SPARC_SE.
When the following code is put before 'store_inst-initiateAcc();'
in LSQUnitImpl::executeStore(..) :
if (store_idx != storeHead) {
memDepViolator = storeQueue[storeHead].inst;
++lsqMemOrderViolation;
return genMachineCheckFault();
}
The following happens:
M5 Simulator System
Copyright (c) 2001-2008
The Regents of The University of Michigan
All Rights Reserved
M5 compiled Jan 25 2011 12:47:37
M5 revision 4c0f7929ee33+ 7842+ default tip
M5 started Jan 25 2011 12:47:44
M5 executing on bellatrix
command line: ./build/SPARC_SE/m5.fast configs/teste.py -n 2 -b Helloworld
-d
Global frequency set at 1 ticks per second
0: system.remote_gdb.listener: listening for remote gdb on port 7000
0: system.remote_gdb.listener: listening for remote gdb on port 7001
info: Entering event queue @ 0. Starting simulation...
panic: Tried to access unmapped address 0x8.
@ cycle 9577000
[invoke:build/SPARC_SE/arch/sparc/faults.cc, line 654]
Memory Usage: 189360 KBytes
For more information see: http://www.m5sim.org/panic/5932f339
Program aborted at cycle 9577000
Aborted
In addition, I also tried not setting the store instruction as executed
when a reordering case is detected in DefaultIEWImpl::executeInsts() :
...
fault = ldstQueue.executeStore(inst);
if(ldstQueue.violation(inst-threadNumber)){
// Don't set as executed
activityThisCycle();
} else
And this happens:
M5 Simulator System
Copyright (c) 2001-2008
The Regents of The University of Michigan
All Rights Reserved
M5 compiled Jan 25 2011 13:21:18
M5 revision 4c0f7929ee33+ 7842+ default tip
M5 started Jan 25 2011 13:21:25
M5 executing on bellatrix
command line: ./build/SPARC_SE/m5.fast configs/teste.py -n 2 -b Helloworld
-d
Global frequency set at 1 ticks per second
0: system.remote_gdb.listener: listening for remote gdb on port 7000
0: system.remote_gdb.listener: listening for remote gdb on port 7001
info: Entering event queue @ 0. Starting simulation...
Exiting @ tick 9223372036854775807 because simulate() limit reached
What can I do to prevent the reordering?
Thanks,
--
Eberle
On Tue, Jan 25, 2011 at 12:37 PM, Steve Reinhardt ste...@gmail.comwrote:
Apparently not...
When you say it didn't work, what do you mean? Maybe if you ask some
more specific questions it will be easier for us to provide some clues.
Steve
On Tue, Jan 25, 2011 at 5:36 AM, Eberle rambo.u...@gmail.com wrote:
Any ideas?
On Fri, Jan 21, 2011 at 5:00 PM, Eberle rambo.u...@gmail.com wrote:
Hi,
How can I enforce the reordering restriction between stores in the O3
(W-W restriction)? To make an store to be executed only after all stores
issued before it were executed.
I tried adding this condition in
Re: [m5-dev] Restricting W-W reordering in O3
Steve, what about adding dependencies between stores in the Memory
Dependency Unit, should it do the trick or needs other modifications?
I've added the restrictions but the result wasn't the expected. Maybe I need
to make more changes in other places?
As I'm using SPARC, I'd need the processor to implement the TSO model, or at
least for now, to not allow reordering between stores.
Thanks in advance,
--
Eberle.
On Tue, Jan 25, 2011 at 1:25 PM, Eberle rambo.u...@gmail.com wrote:
Right, what I need is to prevent the reordering of stores. The stores
should be executed in program order, the oldest store must be executed
before a younger store is allowed to execute.
Using O3 cpu and SPARC_SE.
When the following code is put before 'store_inst-initiateAcc();'
in LSQUnitImpl::executeStore(..) :
if (store_idx != storeHead) {
memDepViolator = storeQueue[storeHead].inst;
++lsqMemOrderViolation;
return genMachineCheckFault();
}
The following happens:
M5 Simulator System
Copyright (c) 2001-2008
The Regents of The University of Michigan
All Rights Reserved
M5 compiled Jan 25 2011 12:47:37
M5 revision 4c0f7929ee33+ 7842+ default tip
M5 started Jan 25 2011 12:47:44
M5 executing on bellatrix
command line: ./build/SPARC_SE/m5.fast configs/teste.py -n 2 -b Helloworld
-d
Global frequency set at 1 ticks per second
0: system.remote_gdb.listener: listening for remote gdb on port 7000
0: system.remote_gdb.listener: listening for remote gdb on port 7001
info: Entering event queue @ 0. Starting simulation...
panic: Tried to access unmapped address 0x8.
@ cycle 9577000
[invoke:build/SPARC_SE/arch/sparc/faults.cc, line 654]
Memory Usage: 189360 KBytes
For more information see: http://www.m5sim.org/panic/5932f339
Program aborted at cycle 9577000
Aborted
In addition, I also tried not setting the store instruction as executed
when a reordering case is detected in DefaultIEWImpl::executeInsts() :
...
fault = ldstQueue.executeStore(inst);
if(ldstQueue.violation(inst-threadNumber)){
// Don't set as executed
activityThisCycle();
} else
And this happens:
M5 Simulator System
Copyright (c) 2001-2008
The Regents of The University of Michigan
All Rights Reserved
M5 compiled Jan 25 2011 13:21:18
M5 revision 4c0f7929ee33+ 7842+ default tip
M5 started Jan 25 2011 13:21:25
M5 executing on bellatrix
command line: ./build/SPARC_SE/m5.fast configs/teste.py -n 2 -b Helloworld
-d
Global frequency set at 1 ticks per second
0: system.remote_gdb.listener: listening for remote gdb on port 7000
0: system.remote_gdb.listener: listening for remote gdb on port 7001
info: Entering event queue @ 0. Starting simulation...
Exiting @ tick 9223372036854775807 because simulate() limit reached
What can I do to prevent the reordering?
Thanks,
--
Eberle
On Tue, Jan 25, 2011 at 12:37 PM, Steve Reinhardt ste...@gmail.comwrote:
Apparently not...
When you say it didn't work, what do you mean? Maybe if you ask some
more specific questions it will be easier for us to provide some clues.
Steve
On Tue, Jan 25, 2011 at 5:36 AM, Eberle rambo.u...@gmail.com wrote:
Any ideas?
On Fri, Jan 21, 2011 at 5:00 PM, Eberle rambo.u...@gmail.com wrote:
Hi,
How can I enforce the reordering restriction between stores in the O3
(W-W restriction)? To make an store to be executed only after all stores
issued before it were executed.
I tried adding this condition in the executeStore method in
lsq_unit_impl.hh, but it didn't work:
if (store_idx != storeHead) {
memDepViolator = storeQueue[storeHead].inst;
return genMachineCheckFault();
}
Thanks,
--
Eberle Rambo.
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Restricting W-W reordering in O3
Any ideas?
On Fri, Jan 21, 2011 at 5:00 PM, Eberle rambo.u...@gmail.com wrote:
Hi,
How can I enforce the reordering restriction between stores in the O3 (W-W
restriction)? To make an store to be executed only after all stores issued
before it were executed.
I tried adding this condition in the executeStore method in
lsq_unit_impl.hh, but it didn't work:
if (store_idx != storeHead) {
memDepViolator = storeQueue[storeHead].inst;
return genMachineCheckFault();
}
Thanks,
--
Eberle Rambo.
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Restricting W-W reordering in O3
Apparently not...
When you say it didn't work, what do you mean? Maybe if you ask some more
specific questions it will be easier for us to provide some clues.
Steve
On Tue, Jan 25, 2011 at 5:36 AM, Eberle rambo.u...@gmail.com wrote:
Any ideas?
On Fri, Jan 21, 2011 at 5:00 PM, Eberle rambo.u...@gmail.com wrote:
Hi,
How can I enforce the reordering restriction between stores in the O3
(W-W restriction)? To make an store to be executed only after all stores
issued before it were executed.
I tried adding this condition in the executeStore method in
lsq_unit_impl.hh, but it didn't work:
if (store_idx != storeHead) {
memDepViolator = storeQueue[storeHead].inst;
return genMachineCheckFault();
}
Thanks,
--
Eberle Rambo.
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Restricting W-W reordering in O3
Right, what I need is to prevent the reordering of stores. The stores should
be executed in program order, the oldest store must be executed before a
younger store is allowed to execute.
Using O3 cpu and SPARC_SE.
When the following code is put before 'store_inst-initiateAcc();'
in LSQUnitImpl::executeStore(..) :
if (store_idx != storeHead) {
memDepViolator = storeQueue[storeHead].inst;
++lsqMemOrderViolation;
return genMachineCheckFault();
}
The following happens:
M5 Simulator System
Copyright (c) 2001-2008
The Regents of The University of Michigan
All Rights Reserved
M5 compiled Jan 25 2011 12:47:37
M5 revision 4c0f7929ee33+ 7842+ default tip
M5 started Jan 25 2011 12:47:44
M5 executing on bellatrix
command line: ./build/SPARC_SE/m5.fast configs/teste.py -n 2 -b Helloworld
-d
Global frequency set at 1 ticks per second
0: system.remote_gdb.listener: listening for remote gdb on port 7000
0: system.remote_gdb.listener: listening for remote gdb on port 7001
info: Entering event queue @ 0. Starting simulation...
panic: Tried to access unmapped address 0x8.
@ cycle 9577000
[invoke:build/SPARC_SE/arch/sparc/faults.cc, line 654]
Memory Usage: 189360 KBytes
For more information see: http://www.m5sim.org/panic/5932f339
Program aborted at cycle 9577000
Aborted
In addition, I also tried not setting the store instruction as executed when
a reordering case is detected in DefaultIEWImpl::executeInsts() :
...
fault = ldstQueue.executeStore(inst);
if(ldstQueue.violation(inst-threadNumber)){
// Don't set as executed
activityThisCycle();
} else
And this happens:
M5 Simulator System
Copyright (c) 2001-2008
The Regents of The University of Michigan
All Rights Reserved
M5 compiled Jan 25 2011 13:21:18
M5 revision 4c0f7929ee33+ 7842+ default tip
M5 started Jan 25 2011 13:21:25
M5 executing on bellatrix
command line: ./build/SPARC_SE/m5.fast configs/teste.py -n 2 -b Helloworld
-d
Global frequency set at 1 ticks per second
0: system.remote_gdb.listener: listening for remote gdb on port 7000
0: system.remote_gdb.listener: listening for remote gdb on port 7001
info: Entering event queue @ 0. Starting simulation...
Exiting @ tick 9223372036854775807 because simulate() limit reached
What can I do to prevent the reordering?
Thanks,
--
Eberle
On Tue, Jan 25, 2011 at 12:37 PM, Steve Reinhardt ste...@gmail.com wrote:
Apparently not...
When you say it didn't work, what do you mean? Maybe if you ask some
more specific questions it will be easier for us to provide some clues.
Steve
On Tue, Jan 25, 2011 at 5:36 AM, Eberle rambo.u...@gmail.com wrote:
Any ideas?
On Fri, Jan 21, 2011 at 5:00 PM, Eberle rambo.u...@gmail.com wrote:
Hi,
How can I enforce the reordering restriction between stores in the O3
(W-W restriction)? To make an store to be executed only after all stores
issued before it were executed.
I tried adding this condition in the executeStore method in
lsq_unit_impl.hh, but it didn't work:
if (store_idx != storeHead) {
memDepViolator = storeQueue[storeHead].inst;
return genMachineCheckFault();
}
Thanks,
--
Eberle Rambo.
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] Restricting W-W reordering in O3
Hi,
How can I enforce the reordering restriction between stores in the O3 (W-W
restriction)? To make an store to be executed only after all stores issued
before it were executed.
I tried adding this condition in the executeStore method in
lsq_unit_impl.hh, but it didn't work:
if (store_idx != storeHead) {
memDepViolator = storeQueue[storeHead].inst;
return genMachineCheckFault();
}
Thanks,
--
Eberle Rambo.
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
