Hi-
I'm repeatedly encountering situations where the MemCtrl stops
scheduling requests even though mem_intr->writeQueueSize is not zero.
Unfortunately I can neither reproduce it in a MWE or by capturing and
playing back a packet sequence. (As a last resort I may resort to time
travel debug capture with the rr utility.)
The problem:
In my simulations the path of execution often ends up on line 964 of
mem_ctrl.cc
https://github.com/gem5/gem5/blob/stable/src/mem/mem_ctrl.cc#L964
where no more events are scheduled even though
(gdb) p mem_intr->writeQueueSize
$1 = 15
And
(gdb) call drainState()
$2 = gem5::DrainState::Running
(gdb) p writeLowThreshold
$3 = 32
(gdb) p mem_intr->writeQueueSize > writeLowThreshold
$4 = false
(gdb) p mem_intr->readQueueSize
$5 = 0
(gdb) p mem_intr->busState
$6 = gem5::memory::qos::MemCtrl::READ
I suspect the culprit is line 1127 of mem_ctrl.cc
https://github.com/gem5/gem5/blob/stable/src/mem/mem_ctrl.cc#L1127
The test:
(below_threshold && drainState() != DrainState::Draining)
returns true and switches the next bus state to READ even through
mem_intr->readQueueSize == 0.
When I explicitly force
mem_intr->busStateNext = MemCtrl::WRITE
MemCtrl processes one write message but sets the next bus state to
MemCtrl::READ. As such I've had to repeatedly force the next state to
MemCtrl::WRITE until mem_intr->writeQueueSize == 0.
Please advise.
Regards,
- Olumide
_______________________________________________
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
