[
https://issues.apache.org/jira/browse/CASSANDRA-11452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15243989#comment-15243989
]
Ben Manes commented on CASSANDRA-11452:
---------------------------------------
The hash table trick isn't applicable since I didn't fork it for Caffeine or
CLHM. I was opposed to Guava's decision to do that, other than for computation,
as I feel the trade-off is sharply negative.
The random walk has a mixed effect in small traces (512 entry). For most its
equivalent, for multi3 its better, and negative otherwise. I think multi3 is
better only because its a mixed workload that is TinyLFU struggles on (in
comparison to LIRS). For larger workloads (database, search, oltp) its
equivalent, as we'd expect. (multi1: -4%, multi3: +3%, gli: -2.5%, cs: -2%)
A 1% random admittance can have a similar 1-2% reduction, but goes away at a
lower rate like 0.4% (1/255). That also passes the collision test since it
causes some jitter. It may not be enough in a more adversarial test.
Branimir had noticed earlier that using _greater or equal to_ was a solution,
but as noted it had a negative impact. However we care mostly about hot
candidates being rejected by an artificially hot victim. Most candidates are
very cold so the filter avoids polluting the cache. If we add a constraint to
the randomization to only be applied to warm candidates then we pass the test
and don't see a degredation. I used a constraint of greater than 5, where the
maximum frequency is 15 (4-bit counters).
I lean towards large traces being more realistic and meaningful, so I am not
overly worried either way. But I would like to keep the small traces in good
standing as they are easy comparisons for understandable patterns.
What are your thoughts on applying the randomness only when the candidate has
at least a moderate frequency?
> 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)
