Wip temperature based object eviction for cache tiering #4737
Conversation
|
Looks cool but why not to implement ARC(https://www.usenix.org/conference/fast-03/arc-self-tuning-low-overhead-replacement-cache) strategy which suits your requirement. |
ghost
added
|
I had a hard time figuring out how to use both atime and temperature--simply choosing which makes sense. I wonder, though, if this is too restrictive. If we calculate both atime and temp values, we can build distributions for both and upper/lower values for each. Here we just pick which one to look at. Instead, we could make the final value we use to decide a weighted average of the two. Is that too complex? The other thing I worry about is that the temp calc is more expensive (looks at all hitsets, not just the last few), so we should avoid doing it if the value won't get used. |
The paper claims the algorithm is very good. However, i am suggesting before we try to introduce some academic outcome, we had better to hear where it has been used, especially in production systems. The paper has been published over ten years anyway. |
For atime, it would make mistake if the object is accessed only once, while enjoying the low complexity; For temperature, it wanna avoid the mistake by looking further back into the history, which, of course, incurring more complexity. So, a straightforward thought, could we make a tradeoff, that is, judge by the last N appreances, that is, a object is calculating its temprature by judging its last N apperances in hitsets. We introduce another parameter, represent N. |
|
@dragonylffly The last N thing makes sense to me. What do you think about a blend of atime and temperature? I'm thinking that a good default policy would take both into consideration... |
|
Updated, please review |
| if (grade_table.size() <= i) | ||
| return 0; | ||
| return grade_table[i]; | ||
| } |
There was a problem hiding this comment.
This seems incomplete. It seems like we need a calc_grade_table() method that is called from the end of decode() and the constructor, and drop the set_grade() callers from random other places (like when the pool is created).
It's a bit dangerous because the parameters are not private... we could change that too so that anybody modifying the parameters necessarily recalculates the table.
|
Updated, please review |
|
Aside from my whitespace nit, my only concern here is that the monitor is setting the grade parameters but the table will remain stable. It all works because only the OSD uses the grades and it never modifies the parameters, but as a standalone data type this is asking for trouble. Can you make those two new fields are private, and add get_foo() and set_foo() accessors? Then the set_ ones can call calc. Thanks! |
|
@liewegas Sorry, I donot quite get your point. The grade_table[] is calculated by 'decay_rate' and 'hitset_count'. When the Monitor sets the values of the two variables, it seems we do not need update grade_table[] immediately, instead, we do it in pg_pool_t::decode() logic when the OSD parses the updated OSDMAP. We could make 'decay_rate' private ( while 'hitset_count', was there long before, is public), intoduce a set() and update grade_table[] in it. But we need distinguish the situation that when Monitor sets the value of 'decay_rate', it should not update the table, it is not called unconditonally . In our current implementation, we make grade_table[] private and update it in pg_pool_t::decode(). It seems ok to us, do we miss anything? |
|
@liewegas Rebased on master, please review the updated codes |
|
I think this looks pretty reasonable. I have two questions:
|
|
@LiumxNL @dragonylffly this needs rebasing |
|
updated :) |
Signed-off-by: MingXin Liu <mingxinliu@ubuntukylin.com> Reviewed-by: Li Wang <liwang@ubuntukylin.com>
Signed-off-by: MingXin Liu <mingxinliu@ubuntukylin.com> Reviewed-by: Li Wang <liwang@ubuntukylin.com>
Signed-off-by: MingXin Liu <mingxinliu@ubuntukylin.com> Reviewed-by: Li Wang <liwang@ubuntukylin.com>
Signed-off-by: MingXin Liu <mingxinliu@ubuntukylin.com> Reviewed-by: Li Wang <liwang@ubuntukylin.com>
Signed-off-by: MingXin Liu <mingxinliu@ubuntukylin.com> Reviewed-by: Li Wang <liwang@ubuntukylin.com>
…tion osd: improve temperature calculation for cache tier agent Reviewed-by: Sage Weil
This is an implementation of temperature based object eviction policy for cache tiering. The current eviction policy is based only on the latest access time, without considering the access frequency in the history. This policy is apt to leave the just-accessed object in the cache pool,
even it will no longer be accessed. Obviously, this policy will make bad choices in some scenarios. This motivates us to present temperature based object eviction policy, which makes eviction decision by considering both latest access time and access frequency, while keeping the simplicity of the current algorithm framework, and making minimal revision to it. The algorithm is simple, associate each hitset with a weight, the latest hitset with the heaviest weight, say, 1000000. And the least latest hitset with a lighter weight, decayed by an user-defined factor, say, 50, then the least latest hitset has a weight of 1000000*(100-50)/100=500000, and so on. Each object in the cache pool will be calculated a total weight according to its appearance in all the hitsets, then those objects with the least total weights are chosen as the eviction candidates. In fact, the algorithm reduces to the current atime based eviction policy by setting decay rate be 100.