(Follow up...)
The reason why Case B does not invoke writeDataToBlock() is that, every
time during writeback, it does not even find the block in
LRU::accessBlock() at the first place. (Note that both Case A and Case B
use the same physicall address to access the L2 cache.) But Case A
actually find the block in cache. I think this is why the data got
contaminated. But why different line sizes lead to such a difference?
Case B does not find the block in L2 is because L1/L2 exclusiveness is
ENFORCED? If yes, then why different line sizes change the whole story?
Thanks.
On 7/22/2010 7:00 PM, Weixun Wang wrote:
Hi there,
I looked through the code for cache block writeback carefully but
found nothing wrong. The physical address used for access the L2 cache
block during a L1 cache block writeback went through a correct
analysis procedure for tag, set index as well as in-block offset.
Therefore, I decided to compare the dumped trace (I added information
printing in each functions through memory access process) between two
scenarios: [Case A] one with L1 line size 32B and L2 line size 64B ;
[Case B] one with the same line sizes, all 32B. Case A leads to a
"unmapped address" error after a while.
There are two categories of differences between two traces. The first
one is that sometimes when it is a L2 cache miss in Case B, it is a L2
cache hit for Case A. It is very understandable since larger L2 line
size brings higher hit rate.
The second kind of differences are most interesting. It is about
d-cache writeback. In both cases, whenever there is a data L1 cache
writeback to L2, it sends a Writeback packet to L2 and L2 does receive
it. HOWEVER, for Case A, L2 cache will call function
Cache<TagStore>::satisfyCpuSideRequest() in which
Packet::writeDataToBlock() is called. While in Case B, these two
functions are NOT called. For example:
[Case A, different L1/L2 cache line sizes]
*** Weixun: system.cpu.dcache-cpu_side_port
SimpleTimingPort::schedSendEvent()
*** Weixun: system.cpu.dcache Cache<TagStore>::handleResponse need
WRITEBACK !!
*** Weixun: system.cpu.dcache-mem_side_port
SimpleTimingPort::schedSendEvent()
*** Weixun: system.cpu.icache-mem_side_port
Cache<TagStore>::MemSidePort::recvTiming() addr = 794080 , cmd =
Writeback , pkt.size = 32
*** Weixun: system.l2c-cpu_side_port
Cache<TagStore>::CpuSidePort::recvTiming() addr = 794080 , cmd =
Writeback , pkt.size = 32
*** Weixun: system.l2c LRU::accessBlock() addr = 794080 , addrStr =
00000000000011000001110111100000
/**** Weixun: system.l2c Cache<TagStore>::satisfyCpuSideRequest()
isWRITE pkt.addr = 794080 , pkt.size = 32 , blk.size = 64 , blkSize = 64
*** Weixun: Packet::writeDataToBlock() blkSize = 64 , block offset = 32 */
*** Weixun: system.l2c Cache<TagStore>::timingAccess() cache HIT!
blk.size = 64
[Case B, same cache line size]
*** Weixun: system.cpu.dcache-cpu_side_port
SimpleTimingPort::schedSendEvent()
*** Weixun: system.cpu.dcache Cache<TagStore>::handleResponse need
WRITEBACK !!
*** Weixun: system.cpu.dcache-mem_side_port
SimpleTimingPort::schedSendEvent()
*** Weixun: system.cpu.icache-mem_side_port
Cache<TagStore>::MemSidePort::recvTiming() addr = 794080 , cmd =
Writeback , pkt.size = 32
*** Weixun: system.l2c-cpu_side_port
Cache<TagStore>::CpuSidePort::recvTiming() addr = 794080 , cmd =
Writeback , pkt.size = 32
*** Weixun: system.l2c LRU::accessBlock() addr = 794080 , addrStr =
00000000000011000001110111100000
*** Weixun: system.l2c Cache<TagStore>::timingAccess() cache HIT!
blk.size = 32
I'm confused. If there is a L1 cache writeback, it must be necessary
to call writeDataToBlock() in order to actually write the data to L2
cache block. If it should not be called, are all the writebacks
handled by the code chuck in Cache<TagStore>::access(...) where it
says "Writeback handling is special case....."?
Any help is appreciated!
Weixun
On 7/21/2010 10:09 PM, Steve Reinhardt wrote:
I think Gabe is right that the memory values in the cache are getting
corrupted leading to the wrong values being used to generate pointers.
The type of problem you suggest with writeback seems like a possible
cause.
Steve
On Wed, Jul 21, 2010 at 11:38 AM, Weixun Wang<[email protected]> wrote:
Thanks for your reply.
I understand that it is not officially supported. But from the source code
and runtime dump info, my understanding is that each step throughout the
memory access process, differences in cache line size seem have been
considered. For example, the data size stored in the packets are
corresponded to the line sizes at each cache level. Maybe, I guess, it's
just about the size but the actual data (e.g. to be written back to L2 from
L1) is not correct? The only place I can think of which may corrupt the data
due to line size differences is when dirty blocks are written back from
d-cache to L2 cache. Am I on the right track?
Weixun
On 7/21/2010 2:21 PM, Gabe Black wrote:
Weixun Wang wrote:
Hi all,
I'm trying to get M5 work with different line sizes in different
caches (i-cache, d-cache and l2). I found that M5 works fine with a
lot of scenarios where different caches have different line sizes
among cores (I verified the simulated apps' outputs). However, when it
comes to some other cases, especially when the L2 cache size is small
(e.g. 32kB), I got errors "Tried to access/execute unmapped address
XXX" from ItbPageFault::invoke() and NDtbMissFault::invoke().
I made M5 dump out messages throughout the memory access process
during simulation. I found that the error is caused by an invalid
virtual address of PC or data address. For example, in the read()
function of TimingSimpleCPU, (system.cpu TimingSimpleCPU::read() addr
= 7776240), the passed in parameter addr (which is the virtual
address) got the value "7776240", which is obviously an invalid
virtual address since in that case normal load/store has the vaddr of
sth like "4832631768". Therefore, the next step, which is calling the
TLB to translate the address, report such an error after looking up
the page table.
There is no error if the line sizes are the same. So I suppose the
error comes from line size differences. But I went through the M5
source code and found that actually memory access has taken the line
size differences among cache levels into consideration by
differentiating "size" stored in Request/Packet and the block size in
each cache. Block filling functions are also written in a right
manner. Moreover, the error comes from a bad virtual address in the
first place, which indeed has nothing to do with cache accesses. I'm
confused...
Any help will be appreciated!
Thanks!
Using different line sizes isn't supported, and it isn't surprising it
doesn't entirely work. It's likely the different sizes corrupted the
virtual address as it was brought in from memory, or corrupted a value
used to compute it. This segfault in the simulated program is probably a
symptom of a problem that happened earlier.
Gabe
_______________________________________________
m5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
--
Best Regards,
Wang, Weixun
Department of Computer& Information Science& Engineering
Gator College of Engineering
University of Florida
Gainesville, FL 32611
http://www.cise.ufl.edu/~wewang
_______________________________________________
m5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
_______________________________________________
m5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
--
Best Regards,
Wang, Weixun
Department of Computer& Information Science& Engineering
Gator College of Engineering
University of Florida
Gainesville, FL 32611
http://www.cise.ufl.edu/~wewang
_______________________________________________
m5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
--
Best Regards,
Wang, Weixun
Department of Computer& Information Science& Engineering
Gator College of Engineering
University of Florida
Gainesville, FL 32611
http://www.cise.ufl.edu/~wewang
_______________________________________________
m5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
