cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ben Manes (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-11452) Cache implementation using LIRS eviction for in-process page cache
Date Sat, 16 Apr 2016 03:42:25 GMT


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

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

> Cache implementation using LIRS eviction for in-process page cache
> ------------------------------------------------------------------
>                 Key: CASSANDRA-11452
>                 URL:
>             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

View raw message