Hello,
Consider following scenario:
At this time, my question is, since original attributes for this line were not "outer cacheable", will the line still may be allocated into L2, or will directly be written to L3, always?
If, L2 is skipped in the above scenario, does that mean the line type information is stored in L1 ? That is, something like AWUSER[4:1] is stored somewhere for each line?
What if L2 is in exclusive cache mode?
Thanks.
Yes, L2 is PL310.
Does this mean the ARCACHEM[3:0]/AWCACHEM[3:0] etc encoding are not honored in the case of evictions from L1, even when data is non-shared?
From PL310 TRM, for Normal non-shared memory:
Table 2-7 Cacheable but do not allocate AXI transactions Outer non cacheable -- Read: Not cached in L2, results in L3 access. Write: Put in store buffer, write to L3 when store buffer is drained.
Table 2-7 Cacheable but do not allocate AXI transactions
Outer non cacheable --
Read: Not cached in L2, results in L3 access.
Write: Put in store buffer, write to L3 when store buffer is drained.
Is the above table invalid in case of evictions of the line which had outer non-cacheable attribute?
Sorry - mistake my side - based on what I can see in the manual PL310 assumes that it is an "outer cache" always; I thought it could be configured as inner or outer as a configuration option, but apparently not.
Table 2-4 in the TRM below gives a pretty complete list of cache behaviors for each memory attribute type - does this answer your question?
http://infocenter.arm.com/help/topic/com.arm.doc.ddi0246a/DDI0246A_l2cc_pl310_r0p0_trm.pdf
This is the same table I am referring to.
Basically, I wanted to confirm that this rule will be followed even on evictions. That is, L1 must store the memory attributes for the region when the line was allocated in L1 and on eviction use the same to propagate to L2.
If the above is correct, then the memory written as inner cacheable, non-outer cacheable, non-shared will never land into L2, right?
If the above is correct, then the memory written as inner cacheable, non-outer cacheable, non-shared will never land into L2, right
Yes, an eviction should be treated like any other write and must honour the page table settings. It looks like outer non-cacheable will never write allocate, but may write into the cache if that line was already present for some reason.
Thanks a lot for confirming.
This fits the observations I had during long tests, still wanted to rule out if this falls into UNPREDICTABLE case.