Cache tier improvements - hitsets proxy write


e should extend the existing HitSet concept to capture more than just "1 or more reads or writes during this N hour period".
We should also merge the proxy-write patches to round out our flexibility for when to promote on the write side as well.


  • Name (Affiliation)
  • Name (Affiliation)
  • Name

Interested Parties

  • Sage Weil (Affiliation)
  • Name (Affiliation)
  • Name

Current Status

Hammer will now proxy reads, which makes our promotion decisions much more flexible. Writes, however, still force a promotion, which prevents us from doing very much to avoid thrashing the cache.
HitSets cover a configurable time period (usually some number of hours) and we insert on any read or write. They tell us if there were 1 or more of those items. We cannot distinguish between 1 read and 10,000 reads. Or reads and writes. Or sequential vs random.

Detailed Description

  1. Merge the write-proxy patches from Zhiqiang Wang
  2. Duplicate the current "recency" logic we use for read for writes.
  3. Track more/better metadata about our workload
    1. how many reads? 1, 10, 100? how can we tell?
    2. reads vs writes?
How to actually do this? Unclear. We could use a counting HitSet, but that will only get us N bits of counting at a cost of N times as much memory/disk overhead. Probably expensive.
We could use a hybrid structure: hash + bloom filter
  • first insert things in a counting structure of bounded size
  • as things fall off, insert them in the bloom filter
  • > hot things get counts, cold things do not.
  • maybe we record the average count for things that fall off too?

We can also cosntruct an efficient MRC (miss ratio curve) to estimate what our reuse-distance is for the workload. This will let us decide how big such a hybrid structure should be. And/or, how big our cache should be. See:

Work items

Coding tasks

  1. test and merge write-proxy series
  2. ??
  3. Profit