Feature #8674
osd: cache tier: avoid promotion on first read
0%
Description
Earlier we proposed adding a new 'read-forward' mode that never promotes on reads (which may make sense for flash). Currently we promote into the cache on first read.
I suspect what will work best for most workloads is something in between, where we promote either on, say, the second read. That is easy: promote only if the object is in the current HitSet.
If we want to promote on 3rd or later read, then it's harder; we'd need to look at multiple HitSets, or make the HitSet a counting bloom filter (potentially useful), or something.
Either way, though, this should either be a tunable that controls the promotion behavior in 'writeback' or 'readonly' cache modes. Another pg_pool_t property?
Related issues
Associated revisions
ceph_test_rados_api_tier: test promote-on-second-read behavior
http://tracker.ceph.com/issues/8674 References: #8674
Signed-off-by: Zhiqiang Wang <wonzhq@hotmail.com>
Signed-off-by: Sage Weil <sage@redhat.com>
(cherry picked from commit 1417eded65f40bdb2a49c8252fcfffa383a7b965)
osd: promotion on 2nd read for cache tiering
http://tracker.ceph.com/issues/8674 Fixes: #8674
Signed-off-by: Zhiqiang Wang <wonzhq@hotmail.com>
(cherry picked from commit 0ed3adc1e0a74bf9548d1d956aece11f019afee0)
History
#1 Updated by Greg Farnum almost 9 years ago
This naively sounds like a terrible idea — you still have maintain metadata on the object (so you know it's the second read, or whatever), and evict that metadata later on, but you're forcing double remote reads. Given that the cost of waiting for the promote is one of our bad performance drivers, I don't see this being worthwhile...
But anyway, do you have any other details on how this might be done, or what issue it's trying to solve?
#2 Updated by Sage Weil almost 9 years ago
- Description updated (diff)
- Source changed from other to Development
#3 Updated by Sage Weil almost 9 years ago
Greg Farnum wrote:
This naively sounds like a terrible idea — you still have maintain metadata on the object (so you know it's the second read, or whatever), and evict that metadata later on, but you're forcing double remote reads. Given that the cost of waiting for the promote is one of our bad performance drivers, I don't see this being worthwhile...
But anyway, do you have any other details on how this might be done, or what issue it's trying to solve?
The idea is that if you have a single read on an object, you don't spend all of the effort doing the writes related to promotion. Or reading the entire backend object (which the read op may not be doing). You only spend the writes putting things into the cache that you have some notion will actually be hot.
#4 Updated by Neil Levine over 8 years ago
- Target version changed from 0.83 cont. to 0.84
#5 Updated by Sage Weil over 8 years ago
- Target version changed from 0.84 to 0.85
#6 Updated by Sage Weil over 8 years ago
- Target version deleted (
0.85)
#7 Updated by Sage Weil over 8 years ago
- Status changed from New to Pending Backport
- Target version set to 0.84 cont.
#8 Updated by Ian Colle over 8 years ago
- Target version changed from 0.84 cont. to 0.88
#9 Updated by Ian Colle over 8 years ago
- Target version changed from 0.88 to v.actually90
#10 Updated by Ian Colle about 8 years ago
- Target version changed from v.actually90 to v0.93 - Last Hammer Sprint
#11 Updated by Nathan Cutler almost 8 years ago
- Backport set to firefly
#12 Updated by Loïc Dachary almost 8 years ago
$ git --no-pager log --oneline 79d1aff1821bc9f21477636df4d0d4e57f2cd008^1..79d1aff1821bc9f21477636df4d0d4e57f2cd008^2 1417ede ceph_test_rados_api_tier: test promote-on-second-read behavior 0ed3adc osd: promotion on 2nd read for cache tiering
#13 Updated by Nathan Cutler over 7 years ago
- Status changed from Pending Backport to Resolved