Write and No-Write Allocate

This is a continuation of a previous post.

In a Write Allocate system, the block is loaded into the Cache on a write miss, followed by the write-hit action. Basically, a Cache block is first allocated before performing the write action. In a No-Write Allocate system, the block is modified directly in the Main Memory and not loaded into the Cache.

Write Back caches generally use Write Allocate (hoping that subsequent writes to that block will be captured by the Cache). Write Through caches often use No-Write allocate (since subsequent writes to that block will still have to go to Main Memory).

Write Through with Write Allocate

HitMiss
Write to Cache and Main MemoryUpdate block in Main Memory and bring the block into the Cache

Bringing the block into the Cache on a Miss does not make a lot of sense in this combination because the next Hit to this block will generate a write to Main Memory anyway (according to Write Through policy)

Write Through with No-Write Allocate

HitMiss
Write to Cache and Main MemoryUpdate block in Main Memory and do not bring the block into the Cache

Subsequent writes to the block will update Main Memory because Write Through policy is employed. So, some time is saved by not bringing the block into the Cache on a miss because it appears useless anyway.

Write Back with Write Allocate

HitMiss
Write to Cache and set dirty bit for that block. Main Memory is not updatedUpdate block in Main Memory and bring the block into the Cache

Subsequent writes to the same block, if the block originally caused a Miss, will Hit in the Cache next time, setting dirty bit for the block. This will eliminate extra memory accesses and result in very efficient execution.

Write Back with No-Write Allocate

HitMiss
Write to Cache and set dirty bit for that block. Main Memory is not updatedUpdate block in Main Memory and do not bring the block into the Cache

Subsequent writes to the same block, if the block originally caused a Miss, will generate Misses all the way and result in very inefficient execution.

Leave a Reply

Your email address will not be published. Required fields are marked *