[ 
https://issues.apache.org/jira/browse/KUDU-613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17903780#comment-17903780
 ] 

ASF subversion and git services commented on KUDU-613:
------------------------------------------------------

Commit 5b6aa7f6baac3eb4c14d9d349f81da5f5b8714c1 in kudu's branch 
refs/heads/master from Mahesh Reddy
[ https://gitbox.apache.org/repos/asf?p=kudu.git;h=5b6aa7f6b ]

KUDU-613: Don't modify refs when moving entries

The current implementation of the SLRU cache temporarily
changes the reference count of entries when moving between
segments of the cache (either during an upgrade or downgrade).
A temporary decrement of the handle's ref count can cause a
concurrent Release call to the entry to think it's the last
reference to the entry and free it when it shouldn't be.

This patch changes this behavior by not modifying the ref
count of entries when moving between segments. A reproduction
scenario to trigger the concurrency error is added to cache-bench.

The existing behavior is to update the mem tracker when moving
entries between segments but that's not necessary. This patch
changes that behavior by not updating the mem tracker for
entries moving between segments.

Change-Id: I643907612d43eba2c5f8dbc19d2f74f88bbca869
Reviewed-on: http://gerrit.cloudera.org:8080/22132
Reviewed-by: Alexey Serbin <ale...@apache.org>
Tested-by: Kudu Jenkins


> Scan-resistant cache replacement algorithm for the block cache
> --------------------------------------------------------------
>
>                 Key: KUDU-613
>                 URL: https://issues.apache.org/jira/browse/KUDU-613
>             Project: Kudu
>          Issue Type: Improvement
>          Components: perf
>    Affects Versions: M4.5
>            Reporter: Andrew Wang
>            Assignee: Mahesh Reddy
>            Priority: Major
>              Labels: performance, roadmap-candidate
>
> The block cache currently uses LRU, which is vulnerable to large scan 
> workloads. It'd be good to implement something like 2Q.
> ARC (patent encumbered, but good for ideas):
> https://www.usenix.org/conference/fast-03/arc-self-tuning-low-overhead-replacement-cache
> HBase (2Q like):
> https://github.com/apache/hbase/blob/master/hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/LruBlockCache.java



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to