Hello all,
These two patches are technically independent, but I bundled them together
because they touch the same code.
The first patch modifies the in-memory metadata to cut 8 bytes per cache block.
It should not change behaviour. The main change is that I removed the 47-bit
wc_entry::index field that looked unnecessary to me. Hopefully someone more
familiar with the code can confirm.
The second patch adds a "clean" state to the cache block (after writing back),
rather than immediately dropping cache blocks after writeback, so that
subsequent reads to that cache block can be served from the cache. This is
primarily useful when the writecache is much bigger than system RAM, so you
can't rely on "recently"-written blocks to still be in the page cache. In this
scenario, one might not want to keep a cache block dirty for long periods
without writing it back to disk, yet still want the cache to provide near-100%
read hits for anything "recently" written (where "recently" could mean multiple
days).
The new "clean" state allows the cache to write back a block, yet still retain
it to serve future reads. It does not modify the eviction policy (no new LRU
tracking), so the writecache is still primarily focused on buffering bursts of
writes. The default behaviour is unchanged: I added a new "evict_clean_blocks"
configuration knob that controls the new behaviour.
To make this work (allow a cache block to be in both the rbtree and the
freelist/freetree at the same time), the in-memory metadata is increased by 8
bytes.
Henry Wong (2):
dm-writecache: Reduce metadata memory use by 8 bytes per cache block.
dm-writecache: Add evict_clean_blocks option to allow read hits on
clean blocks
.../admin-guide/device-mapper/writecache.rst | 19 +-
drivers/md/Kconfig | 5 +-
drivers/md/dm-writecache.c | 187 ++++++++++++------
3 files changed, 141 insertions(+), 70 deletions(-)
--
2.52.0
