[
https://issues.apache.org/jira/browse/CASSANDRA-11452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15242600#comment-15242600
]
Ben Manes commented on CASSANDRA-11452:
---------------------------------------
I chatted with Roy about this problem and he's going to ponder it as well.
I thought about this and toyed with the code a little.
- You're right that my hash detection is very weak and poor enough probably not
bother.
- I do wish Java would add {{longHashCode}} to Object, finally. Its a good
improvement for other platforms.
- Your random walk requires that the attacker can exploit the full walking
distance (last 16) potential victims. The stepwise walk means it could exploit
fewer (e.g. 8) to have an effect, but have to restart when the cache jitters
out. If quantified it might prove the attack impractical.
- Moving the victim to the MRU position after an admission is rejected works at
a small cost to the hit rate. This could be reduced by adding a smaller segment
(e.g. bottom N items) so that we don't degrade the recency effects.
- A sampled bloom filter of past rejections to bypass if TinyLFU present would
probably work well. I think it could also be used to adapt the window size or
improve the hit rate by reducing mispredictions. That would require a lot more
work to evaluate, so impractical for the immediate term.
My plan is to iterate on your random walk. I still think that the victim chosen
should be by the random walk and I haven't grokked your reason not to. I'm
tired so maybe it will be seem obvious later. The long week of production
issues is making me feel pretty slow on this one...
> Cache implementation using LIRS eviction for in-process page cache
> ------------------------------------------------------------------
>
> Key: CASSANDRA-11452
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11452
> Project: Cassandra
> Issue Type: Improvement
> Components: Local Write-Read Paths
> Reporter: Branimir Lambov
> Assignee: Branimir Lambov
>
> Following up from CASSANDRA-5863, to make best use of caching and to avoid
> having to explicitly marking compaction accesses as non-cacheable, we need a
> cache implementation that uses an eviction algorithm that can better handle
> non-recurring accesses.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)