# What if block sizes are not equal among caches?

In all the books, packets of slides and similar I read, cache miss is always explained by assuming that blocks of different caches (or cache and RAM) are always of the same size. It's pretty clear how it's works in this case but the question is: what if block dimensions are not equal among caches?

For example, assuming a L1 cache of 8KB and 16B blocks (that implies 2^9 blocks) and a L2 cache of 512KB with 32B block (that implies 2^14 blocks). Assuming that a load have to be executed, i.e. LD R1,(0x0000AFAF) and suppose that there is a cache L1 miss and a cache L2 hit, what happens? What I mean is that i know that a block containing that addressed byte would be stored in L1 cache and i know where. The problem is what i have to save. I mean, have i to save half block of L2 cache (from 0x0000AFA0 to 0x0000AFAF) in a block of L1 cache or have i to save a block of L2 cache (from 0x0000AFA0 to 0x0000AFBf) in two block of L1 cache? Would be the same if i had cache + RAM instead?

To begin with, block sizes are usually equal across all levels of the cache hierarchy. I would like to see if someone has an example of a commercial architecture where is is not true. There are multiple reasons for this, all of which involve circuit complexity

Now, to answer your question, one could do either. When the processor requests a SP float (4 bytes), only 4 of the 16 (in your example) bytes from the block of the L1 are sent towards the pipeline. The same logic that selects this subset of bytes can be used to select the subset of 16 bytes (in your example) from the incoming block of 32 bytes.

Alternatively, you could over-write the neighboring block in L1 with data from the block of 32 bytes because spatial locality would imply you are likely to require this data soon.

• Examples of (older) "commercial architecture[s] where [th]is is not true": IBM's POWER4 (128B L1 & L2, 512B L3 (four 128B sectors)), Intel's Pentium 4 (L1D 64B lines, L2 128B lines), Intel's Itanium2 (L1 64B lines, L2 & L3, 128B lines).
– user4577
Sep 9, 2015 at 20:51
• @PaulA.Clayton, thanks for those examples! Actually, POWER4, IIRC, still maintained coherence per 128B blocks which greatly simplifies many challenges that come with different block sizes among the caches. The Netburst arch. was an anomaly, in my opinion. Its deep pipeline and Intel's unfathomable need to push the clock as close to 4GHz as possible meant that L1 misses were extremely expensive. Coupled with its aggressive OoO behavior, a larger L2 block size made sense despite the increase in circuit size and power. I cannot find a reason for Itanium to go down that route. Do you know why? Sep 10, 2015 at 13:56
• Thanks for the reply @maverick1989, you're pretty clear. In any case, what about cache and RAM instead of caches? It's the same? Sep 10, 2015 at 14:45
• @giusva, I'd reckon so. Think of the architectural problems that could arise when block sizes differ among the levels. L3 has a block size of 512B, so does memory. However, L2 has a block size of 128B. When L2 incurs a miss, it misses on a single 128B block. If this block exists in L3, a request to L3 can do 1 of 2 things (may be there's others) - L3 can send its entire 512B block (of which, the 128B that missed in L2 are a part) and have the L2 kick out three blocks to fit the entire 512B incoming block. Sep 17, 2015 at 19:30
• Alternatively, it can select (using similar selection logic to what is used by the CPU to select a word out of the supplied block) the appropriate 128B block and send that towards L2. In either case, having the larger block size in L3 does not help much. There can be situations where different block sizes among the memory hierarchy could help. For example, a multicore could benefit by having a larger block size for the LLC if the multiple blocks go to different upper level caches. Sep 17, 2015 at 19:30