[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Cache aliasing on >32k VIPT caches
On Mon, Aug 25, 2008 at 08:27:26AM -0700, Matt Thomas wrote:
> On Aug 25, 2008, at 5:54 AM, Imre Deak wrote:
>> Hi all,
>> according to the ARMv6 TRM:
>> 2. Alternatively, if all mappings to a physical address are of a page
>> size equal to
>> 4KB, then the restriction that bits[13:12] of the Virtual Address
>> must equal
>> bits[13:12] of the physical address is not necessary. Bits[13:12] of
>> all Virtual
>> Address aliases must still be equal.
>> So based on the above at the least we should adhere to 2., I'm
>> guessing that
>> right now there isn't any case where we need 1. The current pmap code
>> only considers
>> bit 12 to distinguish between colors, does this need to be corrected?
>> As far as I
>> understand only bit 12 is significant for picking the cache index and
>> thus color,
>> which would make the current code correct, but then again the TRM
>> might just know
>> __BIT(9 + CPU_CT_xSIZE_SIZE(isize)
>> - CPU_CT_xSIZE_ASSOC(isize))
>> - PAGE_SIZE;
> The code as it exists is correct.
> For 16KB/32KB/64KB, CPU_CT_xSIZE_SIZE(isize) is 0b101 (5) / 0b110 (6) /
> 0b111 (6).
> CPU_CT_xSIZE_ASSOC(size) is always 0b010 (2).
> So the __BIT() expression is __BIT(12), __BIT(13), __BIT(14),
> Which gives a mask of 0, PAGE_SIZE, 3*PAGE_SIZE respectively.
> For both 16KB and 64KB we use the right value, so why doesn't 32KB use
> 3*PAGE_SIZE as well? It has to do with cache organization...
> Each cache line is 32 bytes and we have 4 ways, so that gives us 128
> sets for
> 16KB. Note that 16KB doesn't need page coloring so it must be able map
> address to its unique (set, way).
> Now 64KB needs 512 sets or 4x128 sets. The page color is used to
> which of the four 128-entry sets to place the cache entry. That's why it
> needs to be matched.
> But 32KB only has 256 or 2x128 sets. So there are only two
> possibilities for
> the page color. So while we could use 4 page colors, there is no reason
> the upper bit will be ignored. That will just result in additional
> flushing to no real effect.
Thanks, this is what seems to be logical. The TRM is then too
conservative at this point.
Main Index |
Thread Index |