2016-02-10 00:12:00 +01:00
|
|
|
// Copyright (c) 2011-present, Facebook, Inc. All rights reserved.
|
2013-10-16 23:59:46 +02:00
|
|
|
// This source code is licensed under the BSD-style license found in the
|
|
|
|
// LICENSE file in the root directory of this source tree. An additional grant
|
|
|
|
// of patent rights can be found in the PATENTS file in the same directory.
|
|
|
|
//
|
2011-03-18 23:37:00 +01:00
|
|
|
// Copyright (c) 2011 The LevelDB Authors. All rights reserved.
|
|
|
|
// Use of this source code is governed by a BSD-style license that can be
|
|
|
|
// found in the LICENSE file. See the AUTHORS file for names of contributors.
|
|
|
|
|
2016-08-16 23:43:41 +02:00
|
|
|
#include "util/lru_cache.h"
|
|
|
|
|
2011-03-18 23:37:00 +01:00
|
|
|
#include <assert.h>
|
2011-06-29 02:30:50 +02:00
|
|
|
#include <stdio.h>
|
|
|
|
#include <stdlib.h>
|
2011-03-18 23:37:00 +01:00
|
|
|
|
|
|
|
#include "util/mutexlock.h"
|
|
|
|
|
2013-10-04 06:49:15 +02:00
|
|
|
namespace rocksdb {
|
2011-03-18 23:37:00 +01:00
|
|
|
|
2016-08-16 23:43:41 +02:00
|
|
|
LRUHandleTable::LRUHandleTable() : length_(0), elems_(0), list_(nullptr) {
|
|
|
|
Resize();
|
|
|
|
}
|
2016-07-15 19:41:36 +02:00
|
|
|
|
2016-08-16 23:43:41 +02:00
|
|
|
LRUHandleTable::~LRUHandleTable() {
|
|
|
|
ApplyToAllCacheEntries([](LRUHandle* h) {
|
|
|
|
if (h->refs == 1) {
|
|
|
|
h->Free();
|
Modifed the LRU cache eviction code so that it doesn't evict blocks which have exteranl references
Summary:
Currently, blocks which have more than one reference (ie referenced by something other than cache itself) are evicted from cache. This doesn't make much sense:
- blocks are still in RAM, so the RAM usage reported by the cache is incorrect
- if the same block is needed by another iterator, it will be loaded and decompressed again
This diff changes the reference counting scheme a bit. Previously, if the cache contained the block, this was accounted for in its refcount. After this change, the refcount is only used to track external references. There is a boolean flag which indicates whether or not the block is contained in the cache.
This diff also changes how LRU list is used. Previously, both hashtable and the LRU list contained all blocks. After this change, the LRU list contains blocks with the refcount==0, ie those which can be evicted from the cache.
Note that this change still allows for cache to grow beyond its capacity. This happens when all blocks are pinned (ie refcount>0). This is consistent with the current behavior. The cache's insert function never fails. I spent lots of time trying to make table_reader and other places work with the insert which might failed. It turned out to be pretty hard. It might really destabilize some customers, so finally, I decided against doing this.
table_cache_remove_scan_count_limit option will be unneeded after this change, but I will remove it in the following diff, if this one gets approved
Test Plan: Ran tests, made sure they pass
Reviewers: sdong, ljin
Differential Revision: https://reviews.facebook.net/D25503
2014-10-21 20:49:13 +02:00
|
|
|
}
|
2016-08-16 23:43:41 +02:00
|
|
|
});
|
|
|
|
delete[] list_;
|
|
|
|
}
|
2011-06-29 02:30:50 +02:00
|
|
|
|
2016-08-16 23:43:41 +02:00
|
|
|
LRUHandle* LRUHandleTable::Lookup(const Slice& key, uint32_t hash) {
|
|
|
|
return *FindPointer(key, hash);
|
|
|
|
}
|
2011-06-29 02:30:50 +02:00
|
|
|
|
2016-08-16 23:43:41 +02:00
|
|
|
LRUHandle* LRUHandleTable::Insert(LRUHandle* h) {
|
|
|
|
LRUHandle** ptr = FindPointer(h->key(), h->hash);
|
|
|
|
LRUHandle* old = *ptr;
|
|
|
|
h->next_hash = (old == nullptr ? nullptr : old->next_hash);
|
|
|
|
*ptr = h;
|
|
|
|
if (old == nullptr) {
|
|
|
|
++elems_;
|
|
|
|
if (elems_ > length_) {
|
|
|
|
// Since each cache entry is fairly large, we aim for a small
|
|
|
|
// average linked list length (<= 1).
|
|
|
|
Resize();
|
2011-03-18 23:37:00 +01:00
|
|
|
}
|
2011-06-29 02:30:50 +02:00
|
|
|
}
|
2016-08-16 23:43:41 +02:00
|
|
|
return old;
|
|
|
|
}
|
2011-06-29 02:30:50 +02:00
|
|
|
|
2016-08-16 23:43:41 +02:00
|
|
|
LRUHandle* LRUHandleTable::Remove(const Slice& key, uint32_t hash) {
|
|
|
|
LRUHandle** ptr = FindPointer(key, hash);
|
|
|
|
LRUHandle* result = *ptr;
|
|
|
|
if (result != nullptr) {
|
|
|
|
*ptr = result->next_hash;
|
|
|
|
--elems_;
|
2011-06-29 02:30:50 +02:00
|
|
|
}
|
2016-08-16 23:43:41 +02:00
|
|
|
return result;
|
|
|
|
}
|
2011-06-29 02:30:50 +02:00
|
|
|
|
2016-08-16 23:43:41 +02:00
|
|
|
LRUHandle** LRUHandleTable::FindPointer(const Slice& key, uint32_t hash) {
|
|
|
|
LRUHandle** ptr = &list_[hash & (length_ - 1)];
|
|
|
|
while (*ptr != nullptr && ((*ptr)->hash != hash || key != (*ptr)->key())) {
|
|
|
|
ptr = &(*ptr)->next_hash;
|
2011-06-29 02:30:50 +02:00
|
|
|
}
|
2016-08-16 23:43:41 +02:00
|
|
|
return ptr;
|
|
|
|
}
|
2011-03-18 23:37:00 +01:00
|
|
|
|
2016-08-16 23:43:41 +02:00
|
|
|
void LRUHandleTable::Resize() {
|
|
|
|
uint32_t new_length = 16;
|
|
|
|
while (new_length < elems_ * 1.5) {
|
|
|
|
new_length *= 2;
|
|
|
|
}
|
|
|
|
LRUHandle** new_list = new LRUHandle*[new_length];
|
|
|
|
memset(new_list, 0, sizeof(new_list[0]) * new_length);
|
|
|
|
uint32_t count = 0;
|
|
|
|
for (uint32_t i = 0; i < length_; i++) {
|
|
|
|
LRUHandle* h = list_[i];
|
|
|
|
while (h != nullptr) {
|
|
|
|
LRUHandle* next = h->next_hash;
|
|
|
|
uint32_t hash = h->hash;
|
|
|
|
LRUHandle** ptr = &new_list[hash & (new_length - 1)];
|
|
|
|
h->next_hash = *ptr;
|
|
|
|
*ptr = h;
|
|
|
|
h = next;
|
|
|
|
count++;
|
2011-03-18 23:37:00 +01:00
|
|
|
}
|
2011-06-29 02:30:50 +02:00
|
|
|
}
|
2016-08-16 23:43:41 +02:00
|
|
|
assert(elems_ == count);
|
|
|
|
delete[] list_;
|
|
|
|
list_ = new_list;
|
|
|
|
length_ = new_length;
|
|
|
|
}
|
2011-03-18 23:37:00 +01:00
|
|
|
|
2016-08-20 01:43:31 +02:00
|
|
|
LRUCacheShard::LRUCacheShard()
|
|
|
|
: usage_(0), lru_usage_(0), high_pri_pool_usage_(0) {
|
2011-03-18 23:37:00 +01:00
|
|
|
// Make empty circular linked list
|
|
|
|
lru_.next = &lru_;
|
|
|
|
lru_.prev = &lru_;
|
2016-08-20 01:43:31 +02:00
|
|
|
lru_low_pri_ = &lru_;
|
2011-03-18 23:37:00 +01:00
|
|
|
}
|
|
|
|
|
2016-07-15 19:41:36 +02:00
|
|
|
LRUCacheShard::~LRUCacheShard() {}
|
2011-03-18 23:37:00 +01:00
|
|
|
|
2016-07-15 19:41:36 +02:00
|
|
|
bool LRUCacheShard::Unref(LRUHandle* e) {
|
2011-03-18 23:37:00 +01:00
|
|
|
assert(e->refs > 0);
|
|
|
|
e->refs--;
|
2013-10-08 00:37:40 +02:00
|
|
|
return e->refs == 0;
|
|
|
|
}
|
2013-04-04 03:53:42 +02:00
|
|
|
|
Modifed the LRU cache eviction code so that it doesn't evict blocks which have exteranl references
Summary:
Currently, blocks which have more than one reference (ie referenced by something other than cache itself) are evicted from cache. This doesn't make much sense:
- blocks are still in RAM, so the RAM usage reported by the cache is incorrect
- if the same block is needed by another iterator, it will be loaded and decompressed again
This diff changes the reference counting scheme a bit. Previously, if the cache contained the block, this was accounted for in its refcount. After this change, the refcount is only used to track external references. There is a boolean flag which indicates whether or not the block is contained in the cache.
This diff also changes how LRU list is used. Previously, both hashtable and the LRU list contained all blocks. After this change, the LRU list contains blocks with the refcount==0, ie those which can be evicted from the cache.
Note that this change still allows for cache to grow beyond its capacity. This happens when all blocks are pinned (ie refcount>0). This is consistent with the current behavior. The cache's insert function never fails. I spent lots of time trying to make table_reader and other places work with the insert which might failed. It turned out to be pretty hard. It might really destabilize some customers, so finally, I decided against doing this.
table_cache_remove_scan_count_limit option will be unneeded after this change, but I will remove it in the following diff, if this one gets approved
Test Plan: Ran tests, made sure they pass
Reviewers: sdong, ljin
Differential Revision: https://reviews.facebook.net/D25503
2014-10-21 20:49:13 +02:00
|
|
|
// Call deleter and free
|
2011-03-18 23:37:00 +01:00
|
|
|
|
2016-07-15 19:41:36 +02:00
|
|
|
void LRUCacheShard::EraseUnRefEntries() {
|
Adding pin_l0_filter_and_index_blocks_in_cache feature and related fixes.
Summary:
When a block based table file is opened, if prefetch_index_and_filter is true, it will prefetch the index and filter blocks, putting them into the block cache.
What this feature adds: when a L0 block based table file is opened, if pin_l0_filter_and_index_blocks_in_cache is true in the options (and prefetch_index_and_filter is true), then the filter and index blocks aren't released back to the block cache at the end of BlockBasedTableReader::Open(). Instead the table reader takes ownership of them, hence pinning them, ie. the LRU cache will never push them out. Meanwhile in the table reader, further accesses will not hit the block cache, thus avoiding lock contention.
Test Plan:
'export TEST_TMPDIR=/dev/shm/ && DISABLE_JEMALLOC=1 OPT=-g make all valgrind_check -j32' is OK.
I didn't run the Java tests, I don't have Java set up on my devserver.
Reviewers: sdong
Reviewed By: sdong
Subscribers: andrewkr, dhruba
Differential Revision: https://reviews.facebook.net/D56133
2016-04-01 19:42:39 +02:00
|
|
|
autovector<LRUHandle*> last_reference_list;
|
|
|
|
{
|
|
|
|
MutexLock l(&mutex_);
|
|
|
|
while (lru_.next != &lru_) {
|
|
|
|
LRUHandle* old = lru_.next;
|
2016-08-20 01:43:31 +02:00
|
|
|
assert(old->InCache());
|
Adding pin_l0_filter_and_index_blocks_in_cache feature and related fixes.
Summary:
When a block based table file is opened, if prefetch_index_and_filter is true, it will prefetch the index and filter blocks, putting them into the block cache.
What this feature adds: when a L0 block based table file is opened, if pin_l0_filter_and_index_blocks_in_cache is true in the options (and prefetch_index_and_filter is true), then the filter and index blocks aren't released back to the block cache at the end of BlockBasedTableReader::Open(). Instead the table reader takes ownership of them, hence pinning them, ie. the LRU cache will never push them out. Meanwhile in the table reader, further accesses will not hit the block cache, thus avoiding lock contention.
Test Plan:
'export TEST_TMPDIR=/dev/shm/ && DISABLE_JEMALLOC=1 OPT=-g make all valgrind_check -j32' is OK.
I didn't run the Java tests, I don't have Java set up on my devserver.
Reviewers: sdong
Reviewed By: sdong
Subscribers: andrewkr, dhruba
Differential Revision: https://reviews.facebook.net/D56133
2016-04-01 19:42:39 +02:00
|
|
|
assert(old->refs ==
|
|
|
|
1); // LRU list contains elements which may be evicted
|
|
|
|
LRU_Remove(old);
|
|
|
|
table_.Remove(old->key(), old->hash);
|
2016-08-20 01:43:31 +02:00
|
|
|
old->SetInCache(false);
|
Adding pin_l0_filter_and_index_blocks_in_cache feature and related fixes.
Summary:
When a block based table file is opened, if prefetch_index_and_filter is true, it will prefetch the index and filter blocks, putting them into the block cache.
What this feature adds: when a L0 block based table file is opened, if pin_l0_filter_and_index_blocks_in_cache is true in the options (and prefetch_index_and_filter is true), then the filter and index blocks aren't released back to the block cache at the end of BlockBasedTableReader::Open(). Instead the table reader takes ownership of them, hence pinning them, ie. the LRU cache will never push them out. Meanwhile in the table reader, further accesses will not hit the block cache, thus avoiding lock contention.
Test Plan:
'export TEST_TMPDIR=/dev/shm/ && DISABLE_JEMALLOC=1 OPT=-g make all valgrind_check -j32' is OK.
I didn't run the Java tests, I don't have Java set up on my devserver.
Reviewers: sdong
Reviewed By: sdong
Subscribers: andrewkr, dhruba
Differential Revision: https://reviews.facebook.net/D56133
2016-04-01 19:42:39 +02:00
|
|
|
Unref(old);
|
|
|
|
usage_ -= old->charge;
|
|
|
|
last_reference_list.push_back(old);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
for (auto entry : last_reference_list) {
|
|
|
|
entry->Free();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-07-15 19:41:36 +02:00
|
|
|
void LRUCacheShard::ApplyToAllCacheEntries(void (*callback)(void*, size_t),
|
|
|
|
bool thread_safe) {
|
2014-05-02 22:24:04 +02:00
|
|
|
if (thread_safe) {
|
|
|
|
mutex_.Lock();
|
|
|
|
}
|
2016-05-24 08:35:23 +02:00
|
|
|
table_.ApplyToAllCacheEntries(
|
|
|
|
[callback](LRUHandle* h) { callback(h->value, h->charge); });
|
2014-05-02 22:24:04 +02:00
|
|
|
if (thread_safe) {
|
|
|
|
mutex_.Unlock();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-08-20 01:43:31 +02:00
|
|
|
void LRUCacheShard::TEST_GetLRUList(LRUHandle** lru, LRUHandle** lru_low_pri) {
|
|
|
|
*lru = &lru_;
|
|
|
|
*lru_low_pri = lru_low_pri_;
|
|
|
|
}
|
|
|
|
|
2016-07-15 19:41:36 +02:00
|
|
|
void LRUCacheShard::LRU_Remove(LRUHandle* e) {
|
Modifed the LRU cache eviction code so that it doesn't evict blocks which have exteranl references
Summary:
Currently, blocks which have more than one reference (ie referenced by something other than cache itself) are evicted from cache. This doesn't make much sense:
- blocks are still in RAM, so the RAM usage reported by the cache is incorrect
- if the same block is needed by another iterator, it will be loaded and decompressed again
This diff changes the reference counting scheme a bit. Previously, if the cache contained the block, this was accounted for in its refcount. After this change, the refcount is only used to track external references. There is a boolean flag which indicates whether or not the block is contained in the cache.
This diff also changes how LRU list is used. Previously, both hashtable and the LRU list contained all blocks. After this change, the LRU list contains blocks with the refcount==0, ie those which can be evicted from the cache.
Note that this change still allows for cache to grow beyond its capacity. This happens when all blocks are pinned (ie refcount>0). This is consistent with the current behavior. The cache's insert function never fails. I spent lots of time trying to make table_reader and other places work with the insert which might failed. It turned out to be pretty hard. It might really destabilize some customers, so finally, I decided against doing this.
table_cache_remove_scan_count_limit option will be unneeded after this change, but I will remove it in the following diff, if this one gets approved
Test Plan: Ran tests, made sure they pass
Reviewers: sdong, ljin
Differential Revision: https://reviews.facebook.net/D25503
2014-10-21 20:49:13 +02:00
|
|
|
assert(e->next != nullptr);
|
|
|
|
assert(e->prev != nullptr);
|
2016-08-20 01:43:31 +02:00
|
|
|
if (lru_low_pri_ == e) {
|
|
|
|
lru_low_pri_ = e->prev;
|
|
|
|
}
|
2011-03-18 23:37:00 +01:00
|
|
|
e->next->prev = e->prev;
|
|
|
|
e->prev->next = e->next;
|
Modifed the LRU cache eviction code so that it doesn't evict blocks which have exteranl references
Summary:
Currently, blocks which have more than one reference (ie referenced by something other than cache itself) are evicted from cache. This doesn't make much sense:
- blocks are still in RAM, so the RAM usage reported by the cache is incorrect
- if the same block is needed by another iterator, it will be loaded and decompressed again
This diff changes the reference counting scheme a bit. Previously, if the cache contained the block, this was accounted for in its refcount. After this change, the refcount is only used to track external references. There is a boolean flag which indicates whether or not the block is contained in the cache.
This diff also changes how LRU list is used. Previously, both hashtable and the LRU list contained all blocks. After this change, the LRU list contains blocks with the refcount==0, ie those which can be evicted from the cache.
Note that this change still allows for cache to grow beyond its capacity. This happens when all blocks are pinned (ie refcount>0). This is consistent with the current behavior. The cache's insert function never fails. I spent lots of time trying to make table_reader and other places work with the insert which might failed. It turned out to be pretty hard. It might really destabilize some customers, so finally, I decided against doing this.
table_cache_remove_scan_count_limit option will be unneeded after this change, but I will remove it in the following diff, if this one gets approved
Test Plan: Ran tests, made sure they pass
Reviewers: sdong, ljin
Differential Revision: https://reviews.facebook.net/D25503
2014-10-21 20:49:13 +02:00
|
|
|
e->prev = e->next = nullptr;
|
2015-06-18 22:56:31 +02:00
|
|
|
lru_usage_ -= e->charge;
|
2016-08-20 01:43:31 +02:00
|
|
|
if (e->InHighPriPool()) {
|
|
|
|
assert(high_pri_pool_usage_ >= e->charge);
|
|
|
|
high_pri_pool_usage_ -= e->charge;
|
|
|
|
}
|
2011-03-18 23:37:00 +01:00
|
|
|
}
|
|
|
|
|
2016-08-20 01:43:31 +02:00
|
|
|
void LRUCacheShard::LRU_Insert(LRUHandle* e) {
|
Modifed the LRU cache eviction code so that it doesn't evict blocks which have exteranl references
Summary:
Currently, blocks which have more than one reference (ie referenced by something other than cache itself) are evicted from cache. This doesn't make much sense:
- blocks are still in RAM, so the RAM usage reported by the cache is incorrect
- if the same block is needed by another iterator, it will be loaded and decompressed again
This diff changes the reference counting scheme a bit. Previously, if the cache contained the block, this was accounted for in its refcount. After this change, the refcount is only used to track external references. There is a boolean flag which indicates whether or not the block is contained in the cache.
This diff also changes how LRU list is used. Previously, both hashtable and the LRU list contained all blocks. After this change, the LRU list contains blocks with the refcount==0, ie those which can be evicted from the cache.
Note that this change still allows for cache to grow beyond its capacity. This happens when all blocks are pinned (ie refcount>0). This is consistent with the current behavior. The cache's insert function never fails. I spent lots of time trying to make table_reader and other places work with the insert which might failed. It turned out to be pretty hard. It might really destabilize some customers, so finally, I decided against doing this.
table_cache_remove_scan_count_limit option will be unneeded after this change, but I will remove it in the following diff, if this one gets approved
Test Plan: Ran tests, made sure they pass
Reviewers: sdong, ljin
Differential Revision: https://reviews.facebook.net/D25503
2014-10-21 20:49:13 +02:00
|
|
|
assert(e->next == nullptr);
|
|
|
|
assert(e->prev == nullptr);
|
2016-08-20 01:43:31 +02:00
|
|
|
if (high_pri_pool_ratio_ > 0 && e->IsHighPri()) {
|
|
|
|
// Inset "e" to head of LRU list.
|
|
|
|
e->next = &lru_;
|
|
|
|
e->prev = lru_.prev;
|
|
|
|
e->prev->next = e;
|
|
|
|
e->next->prev = e;
|
|
|
|
e->SetInHighPriPool(true);
|
|
|
|
high_pri_pool_usage_ += e->charge;
|
|
|
|
MaintainPoolSize();
|
|
|
|
} else {
|
|
|
|
// Insert "e" to the head of low-pri pool. Note that when
|
|
|
|
// high_pri_pool_ratio is 0, head of low-pri pool is also head of LRU list.
|
|
|
|
e->next = lru_low_pri_->next;
|
|
|
|
e->prev = lru_low_pri_;
|
|
|
|
e->prev->next = e;
|
|
|
|
e->next->prev = e;
|
|
|
|
e->SetInHighPriPool(false);
|
|
|
|
lru_low_pri_ = e;
|
|
|
|
}
|
2015-06-18 22:56:31 +02:00
|
|
|
lru_usage_ += e->charge;
|
2011-03-18 23:37:00 +01:00
|
|
|
}
|
|
|
|
|
2016-08-20 01:43:31 +02:00
|
|
|
void LRUCacheShard::MaintainPoolSize() {
|
|
|
|
while (high_pri_pool_usage_ > high_pri_pool_capacity_) {
|
|
|
|
// Overflow last entry in high-pri pool to low-pri pool.
|
|
|
|
lru_low_pri_ = lru_low_pri_->next;
|
|
|
|
assert(lru_low_pri_ != &lru_);
|
|
|
|
lru_low_pri_->SetInHighPriPool(false);
|
|
|
|
high_pri_pool_usage_ -= lru_low_pri_->charge;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-07-15 19:41:36 +02:00
|
|
|
void LRUCacheShard::EvictFromLRU(size_t charge,
|
|
|
|
autovector<LRUHandle*>* deleted) {
|
2015-04-24 23:12:58 +02:00
|
|
|
while (usage_ + charge > capacity_ && lru_.next != &lru_) {
|
|
|
|
LRUHandle* old = lru_.next;
|
2016-08-20 01:43:31 +02:00
|
|
|
assert(old->InCache());
|
2015-04-24 23:12:58 +02:00
|
|
|
assert(old->refs == 1); // LRU list contains elements which may be evicted
|
|
|
|
LRU_Remove(old);
|
|
|
|
table_.Remove(old->key(), old->hash);
|
2016-08-20 01:43:31 +02:00
|
|
|
old->SetInCache(false);
|
2015-04-24 23:12:58 +02:00
|
|
|
Unref(old);
|
|
|
|
usage_ -= old->charge;
|
|
|
|
deleted->push_back(old);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-07-15 19:41:36 +02:00
|
|
|
void LRUCacheShard::SetCapacity(size_t capacity) {
|
2015-04-24 23:12:58 +02:00
|
|
|
autovector<LRUHandle*> last_reference_list;
|
|
|
|
{
|
|
|
|
MutexLock l(&mutex_);
|
|
|
|
capacity_ = capacity;
|
2016-08-20 01:43:31 +02:00
|
|
|
high_pri_pool_capacity_ = capacity_ * high_pri_pool_ratio_;
|
2015-04-24 23:12:58 +02:00
|
|
|
EvictFromLRU(0, &last_reference_list);
|
|
|
|
}
|
|
|
|
// we free the entries here outside of mutex for
|
|
|
|
// performance reasons
|
|
|
|
for (auto entry : last_reference_list) {
|
|
|
|
entry->Free();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-07-15 19:41:36 +02:00
|
|
|
void LRUCacheShard::SetStrictCapacityLimit(bool strict_capacity_limit) {
|
2016-03-11 02:35:19 +01:00
|
|
|
MutexLock l(&mutex_);
|
|
|
|
strict_capacity_limit_ = strict_capacity_limit;
|
|
|
|
}
|
|
|
|
|
2016-07-15 19:41:36 +02:00
|
|
|
Cache::Handle* LRUCacheShard::Lookup(const Slice& key, uint32_t hash) {
|
2011-03-18 23:37:00 +01:00
|
|
|
MutexLock l(&mutex_);
|
2011-08-22 23:08:51 +02:00
|
|
|
LRUHandle* e = table_.Lookup(key, hash);
|
2013-03-01 03:04:58 +01:00
|
|
|
if (e != nullptr) {
|
2016-08-20 01:43:31 +02:00
|
|
|
assert(e->InCache());
|
Modifed the LRU cache eviction code so that it doesn't evict blocks which have exteranl references
Summary:
Currently, blocks which have more than one reference (ie referenced by something other than cache itself) are evicted from cache. This doesn't make much sense:
- blocks are still in RAM, so the RAM usage reported by the cache is incorrect
- if the same block is needed by another iterator, it will be loaded and decompressed again
This diff changes the reference counting scheme a bit. Previously, if the cache contained the block, this was accounted for in its refcount. After this change, the refcount is only used to track external references. There is a boolean flag which indicates whether or not the block is contained in the cache.
This diff also changes how LRU list is used. Previously, both hashtable and the LRU list contained all blocks. After this change, the LRU list contains blocks with the refcount==0, ie those which can be evicted from the cache.
Note that this change still allows for cache to grow beyond its capacity. This happens when all blocks are pinned (ie refcount>0). This is consistent with the current behavior. The cache's insert function never fails. I spent lots of time trying to make table_reader and other places work with the insert which might failed. It turned out to be pretty hard. It might really destabilize some customers, so finally, I decided against doing this.
table_cache_remove_scan_count_limit option will be unneeded after this change, but I will remove it in the following diff, if this one gets approved
Test Plan: Ran tests, made sure they pass
Reviewers: sdong, ljin
Differential Revision: https://reviews.facebook.net/D25503
2014-10-21 20:49:13 +02:00
|
|
|
if (e->refs == 1) {
|
|
|
|
LRU_Remove(e);
|
|
|
|
}
|
2011-03-18 23:37:00 +01:00
|
|
|
e->refs++;
|
|
|
|
}
|
2011-08-22 23:08:51 +02:00
|
|
|
return reinterpret_cast<Cache::Handle*>(e);
|
2011-03-18 23:37:00 +01:00
|
|
|
}
|
|
|
|
|
2016-08-20 01:43:31 +02:00
|
|
|
void LRUCacheShard::SetHighPriorityPoolRatio(double high_pri_pool_ratio) {
|
|
|
|
MutexLock l(&mutex_);
|
|
|
|
high_pri_pool_ratio_ = high_pri_pool_ratio;
|
|
|
|
high_pri_pool_capacity_ = capacity_ * high_pri_pool_ratio_;
|
|
|
|
MaintainPoolSize();
|
|
|
|
}
|
|
|
|
|
2016-07-15 19:41:36 +02:00
|
|
|
void LRUCacheShard::Release(Cache::Handle* handle) {
|
2016-03-11 02:35:19 +01:00
|
|
|
if (handle == nullptr) {
|
|
|
|
return;
|
|
|
|
}
|
2013-10-08 00:37:40 +02:00
|
|
|
LRUHandle* e = reinterpret_cast<LRUHandle*>(handle);
|
|
|
|
bool last_reference = false;
|
|
|
|
{
|
|
|
|
MutexLock l(&mutex_);
|
|
|
|
last_reference = Unref(e);
|
Modifed the LRU cache eviction code so that it doesn't evict blocks which have exteranl references
Summary:
Currently, blocks which have more than one reference (ie referenced by something other than cache itself) are evicted from cache. This doesn't make much sense:
- blocks are still in RAM, so the RAM usage reported by the cache is incorrect
- if the same block is needed by another iterator, it will be loaded and decompressed again
This diff changes the reference counting scheme a bit. Previously, if the cache contained the block, this was accounted for in its refcount. After this change, the refcount is only used to track external references. There is a boolean flag which indicates whether or not the block is contained in the cache.
This diff also changes how LRU list is used. Previously, both hashtable and the LRU list contained all blocks. After this change, the LRU list contains blocks with the refcount==0, ie those which can be evicted from the cache.
Note that this change still allows for cache to grow beyond its capacity. This happens when all blocks are pinned (ie refcount>0). This is consistent with the current behavior. The cache's insert function never fails. I spent lots of time trying to make table_reader and other places work with the insert which might failed. It turned out to be pretty hard. It might really destabilize some customers, so finally, I decided against doing this.
table_cache_remove_scan_count_limit option will be unneeded after this change, but I will remove it in the following diff, if this one gets approved
Test Plan: Ran tests, made sure they pass
Reviewers: sdong, ljin
Differential Revision: https://reviews.facebook.net/D25503
2014-10-21 20:49:13 +02:00
|
|
|
if (last_reference) {
|
|
|
|
usage_ -= e->charge;
|
|
|
|
}
|
2016-08-20 01:43:31 +02:00
|
|
|
if (e->refs == 1 && e->InCache()) {
|
Modifed the LRU cache eviction code so that it doesn't evict blocks which have exteranl references
Summary:
Currently, blocks which have more than one reference (ie referenced by something other than cache itself) are evicted from cache. This doesn't make much sense:
- blocks are still in RAM, so the RAM usage reported by the cache is incorrect
- if the same block is needed by another iterator, it will be loaded and decompressed again
This diff changes the reference counting scheme a bit. Previously, if the cache contained the block, this was accounted for in its refcount. After this change, the refcount is only used to track external references. There is a boolean flag which indicates whether or not the block is contained in the cache.
This diff also changes how LRU list is used. Previously, both hashtable and the LRU list contained all blocks. After this change, the LRU list contains blocks with the refcount==0, ie those which can be evicted from the cache.
Note that this change still allows for cache to grow beyond its capacity. This happens when all blocks are pinned (ie refcount>0). This is consistent with the current behavior. The cache's insert function never fails. I spent lots of time trying to make table_reader and other places work with the insert which might failed. It turned out to be pretty hard. It might really destabilize some customers, so finally, I decided against doing this.
table_cache_remove_scan_count_limit option will be unneeded after this change, but I will remove it in the following diff, if this one gets approved
Test Plan: Ran tests, made sure they pass
Reviewers: sdong, ljin
Differential Revision: https://reviews.facebook.net/D25503
2014-10-21 20:49:13 +02:00
|
|
|
// The item is still in cache, and nobody else holds a reference to it
|
|
|
|
if (usage_ > capacity_) {
|
|
|
|
// the cache is full
|
|
|
|
// The LRU list must be empty since the cache is full
|
|
|
|
assert(lru_.next == &lru_);
|
|
|
|
// take this opportunity and remove the item
|
|
|
|
table_.Remove(e->key(), e->hash);
|
2016-08-20 01:43:31 +02:00
|
|
|
e->SetInCache(false);
|
Modifed the LRU cache eviction code so that it doesn't evict blocks which have exteranl references
Summary:
Currently, blocks which have more than one reference (ie referenced by something other than cache itself) are evicted from cache. This doesn't make much sense:
- blocks are still in RAM, so the RAM usage reported by the cache is incorrect
- if the same block is needed by another iterator, it will be loaded and decompressed again
This diff changes the reference counting scheme a bit. Previously, if the cache contained the block, this was accounted for in its refcount. After this change, the refcount is only used to track external references. There is a boolean flag which indicates whether or not the block is contained in the cache.
This diff also changes how LRU list is used. Previously, both hashtable and the LRU list contained all blocks. After this change, the LRU list contains blocks with the refcount==0, ie those which can be evicted from the cache.
Note that this change still allows for cache to grow beyond its capacity. This happens when all blocks are pinned (ie refcount>0). This is consistent with the current behavior. The cache's insert function never fails. I spent lots of time trying to make table_reader and other places work with the insert which might failed. It turned out to be pretty hard. It might really destabilize some customers, so finally, I decided against doing this.
table_cache_remove_scan_count_limit option will be unneeded after this change, but I will remove it in the following diff, if this one gets approved
Test Plan: Ran tests, made sure they pass
Reviewers: sdong, ljin
Differential Revision: https://reviews.facebook.net/D25503
2014-10-21 20:49:13 +02:00
|
|
|
Unref(e);
|
|
|
|
usage_ -= e->charge;
|
|
|
|
last_reference = true;
|
|
|
|
} else {
|
|
|
|
// put the item on the list to be potentially freed
|
2016-08-20 01:43:31 +02:00
|
|
|
LRU_Insert(e);
|
Modifed the LRU cache eviction code so that it doesn't evict blocks which have exteranl references
Summary:
Currently, blocks which have more than one reference (ie referenced by something other than cache itself) are evicted from cache. This doesn't make much sense:
- blocks are still in RAM, so the RAM usage reported by the cache is incorrect
- if the same block is needed by another iterator, it will be loaded and decompressed again
This diff changes the reference counting scheme a bit. Previously, if the cache contained the block, this was accounted for in its refcount. After this change, the refcount is only used to track external references. There is a boolean flag which indicates whether or not the block is contained in the cache.
This diff also changes how LRU list is used. Previously, both hashtable and the LRU list contained all blocks. After this change, the LRU list contains blocks with the refcount==0, ie those which can be evicted from the cache.
Note that this change still allows for cache to grow beyond its capacity. This happens when all blocks are pinned (ie refcount>0). This is consistent with the current behavior. The cache's insert function never fails. I spent lots of time trying to make table_reader and other places work with the insert which might failed. It turned out to be pretty hard. It might really destabilize some customers, so finally, I decided against doing this.
table_cache_remove_scan_count_limit option will be unneeded after this change, but I will remove it in the following diff, if this one gets approved
Test Plan: Ran tests, made sure they pass
Reviewers: sdong, ljin
Differential Revision: https://reviews.facebook.net/D25503
2014-10-21 20:49:13 +02:00
|
|
|
}
|
|
|
|
}
|
2013-10-08 00:37:40 +02:00
|
|
|
}
|
Modifed the LRU cache eviction code so that it doesn't evict blocks which have exteranl references
Summary:
Currently, blocks which have more than one reference (ie referenced by something other than cache itself) are evicted from cache. This doesn't make much sense:
- blocks are still in RAM, so the RAM usage reported by the cache is incorrect
- if the same block is needed by another iterator, it will be loaded and decompressed again
This diff changes the reference counting scheme a bit. Previously, if the cache contained the block, this was accounted for in its refcount. After this change, the refcount is only used to track external references. There is a boolean flag which indicates whether or not the block is contained in the cache.
This diff also changes how LRU list is used. Previously, both hashtable and the LRU list contained all blocks. After this change, the LRU list contains blocks with the refcount==0, ie those which can be evicted from the cache.
Note that this change still allows for cache to grow beyond its capacity. This happens when all blocks are pinned (ie refcount>0). This is consistent with the current behavior. The cache's insert function never fails. I spent lots of time trying to make table_reader and other places work with the insert which might failed. It turned out to be pretty hard. It might really destabilize some customers, so finally, I decided against doing this.
table_cache_remove_scan_count_limit option will be unneeded after this change, but I will remove it in the following diff, if this one gets approved
Test Plan: Ran tests, made sure they pass
Reviewers: sdong, ljin
Differential Revision: https://reviews.facebook.net/D25503
2014-10-21 20:49:13 +02:00
|
|
|
|
|
|
|
// free outside of mutex
|
2013-10-08 00:37:40 +02:00
|
|
|
if (last_reference) {
|
Modifed the LRU cache eviction code so that it doesn't evict blocks which have exteranl references
Summary:
Currently, blocks which have more than one reference (ie referenced by something other than cache itself) are evicted from cache. This doesn't make much sense:
- blocks are still in RAM, so the RAM usage reported by the cache is incorrect
- if the same block is needed by another iterator, it will be loaded and decompressed again
This diff changes the reference counting scheme a bit. Previously, if the cache contained the block, this was accounted for in its refcount. After this change, the refcount is only used to track external references. There is a boolean flag which indicates whether or not the block is contained in the cache.
This diff also changes how LRU list is used. Previously, both hashtable and the LRU list contained all blocks. After this change, the LRU list contains blocks with the refcount==0, ie those which can be evicted from the cache.
Note that this change still allows for cache to grow beyond its capacity. This happens when all blocks are pinned (ie refcount>0). This is consistent with the current behavior. The cache's insert function never fails. I spent lots of time trying to make table_reader and other places work with the insert which might failed. It turned out to be pretty hard. It might really destabilize some customers, so finally, I decided against doing this.
table_cache_remove_scan_count_limit option will be unneeded after this change, but I will remove it in the following diff, if this one gets approved
Test Plan: Ran tests, made sure they pass
Reviewers: sdong, ljin
Differential Revision: https://reviews.facebook.net/D25503
2014-10-21 20:49:13 +02:00
|
|
|
e->Free();
|
2013-10-08 00:37:40 +02:00
|
|
|
}
|
2011-03-18 23:37:00 +01:00
|
|
|
}
|
|
|
|
|
2016-07-15 19:41:36 +02:00
|
|
|
Status LRUCacheShard::Insert(const Slice& key, uint32_t hash, void* value,
|
|
|
|
size_t charge,
|
|
|
|
void (*deleter)(const Slice& key, void* value),
|
2016-08-20 01:43:31 +02:00
|
|
|
Cache::Handle** handle, Cache::Priority priority) {
|
Modifed the LRU cache eviction code so that it doesn't evict blocks which have exteranl references
Summary:
Currently, blocks which have more than one reference (ie referenced by something other than cache itself) are evicted from cache. This doesn't make much sense:
- blocks are still in RAM, so the RAM usage reported by the cache is incorrect
- if the same block is needed by another iterator, it will be loaded and decompressed again
This diff changes the reference counting scheme a bit. Previously, if the cache contained the block, this was accounted for in its refcount. After this change, the refcount is only used to track external references. There is a boolean flag which indicates whether or not the block is contained in the cache.
This diff also changes how LRU list is used. Previously, both hashtable and the LRU list contained all blocks. After this change, the LRU list contains blocks with the refcount==0, ie those which can be evicted from the cache.
Note that this change still allows for cache to grow beyond its capacity. This happens when all blocks are pinned (ie refcount>0). This is consistent with the current behavior. The cache's insert function never fails. I spent lots of time trying to make table_reader and other places work with the insert which might failed. It turned out to be pretty hard. It might really destabilize some customers, so finally, I decided against doing this.
table_cache_remove_scan_count_limit option will be unneeded after this change, but I will remove it in the following diff, if this one gets approved
Test Plan: Ran tests, made sure they pass
Reviewers: sdong, ljin
Differential Revision: https://reviews.facebook.net/D25503
2014-10-21 20:49:13 +02:00
|
|
|
// Allocate the memory here outside of the mutex
|
|
|
|
// If the cache is full, we'll have to release it
|
|
|
|
// It shouldn't happen very often though.
|
2015-12-05 00:12:07 +01:00
|
|
|
LRUHandle* e = reinterpret_cast<LRUHandle*>(
|
2016-05-24 08:35:23 +02:00
|
|
|
new char[sizeof(LRUHandle) - 1 + key.size()]);
|
2016-03-11 02:35:19 +01:00
|
|
|
Status s;
|
2014-01-02 20:26:57 +01:00
|
|
|
autovector<LRUHandle*> last_reference_list;
|
2013-12-11 17:33:29 +01:00
|
|
|
|
|
|
|
e->value = value;
|
|
|
|
e->deleter = deleter;
|
|
|
|
e->charge = charge;
|
|
|
|
e->key_length = key.size();
|
|
|
|
e->hash = hash;
|
2016-03-11 02:35:19 +01:00
|
|
|
e->refs = (handle == nullptr
|
|
|
|
? 1
|
|
|
|
: 2); // One from LRUCache, one for the returned handle
|
Modifed the LRU cache eviction code so that it doesn't evict blocks which have exteranl references
Summary:
Currently, blocks which have more than one reference (ie referenced by something other than cache itself) are evicted from cache. This doesn't make much sense:
- blocks are still in RAM, so the RAM usage reported by the cache is incorrect
- if the same block is needed by another iterator, it will be loaded and decompressed again
This diff changes the reference counting scheme a bit. Previously, if the cache contained the block, this was accounted for in its refcount. After this change, the refcount is only used to track external references. There is a boolean flag which indicates whether or not the block is contained in the cache.
This diff also changes how LRU list is used. Previously, both hashtable and the LRU list contained all blocks. After this change, the LRU list contains blocks with the refcount==0, ie those which can be evicted from the cache.
Note that this change still allows for cache to grow beyond its capacity. This happens when all blocks are pinned (ie refcount>0). This is consistent with the current behavior. The cache's insert function never fails. I spent lots of time trying to make table_reader and other places work with the insert which might failed. It turned out to be pretty hard. It might really destabilize some customers, so finally, I decided against doing this.
table_cache_remove_scan_count_limit option will be unneeded after this change, but I will remove it in the following diff, if this one gets approved
Test Plan: Ran tests, made sure they pass
Reviewers: sdong, ljin
Differential Revision: https://reviews.facebook.net/D25503
2014-10-21 20:49:13 +02:00
|
|
|
e->next = e->prev = nullptr;
|
2016-08-20 01:43:31 +02:00
|
|
|
e->SetInCache(true);
|
|
|
|
e->SetPriority(priority);
|
2013-12-11 17:33:29 +01:00
|
|
|
memcpy(e->key_data, key.data(), key.size());
|
2013-10-08 00:37:40 +02:00
|
|
|
|
|
|
|
{
|
|
|
|
MutexLock l(&mutex_);
|
|
|
|
|
2013-10-10 02:04:40 +02:00
|
|
|
// Free the space following strict LRU policy until enough space
|
Modifed the LRU cache eviction code so that it doesn't evict blocks which have exteranl references
Summary:
Currently, blocks which have more than one reference (ie referenced by something other than cache itself) are evicted from cache. This doesn't make much sense:
- blocks are still in RAM, so the RAM usage reported by the cache is incorrect
- if the same block is needed by another iterator, it will be loaded and decompressed again
This diff changes the reference counting scheme a bit. Previously, if the cache contained the block, this was accounted for in its refcount. After this change, the refcount is only used to track external references. There is a boolean flag which indicates whether or not the block is contained in the cache.
This diff also changes how LRU list is used. Previously, both hashtable and the LRU list contained all blocks. After this change, the LRU list contains blocks with the refcount==0, ie those which can be evicted from the cache.
Note that this change still allows for cache to grow beyond its capacity. This happens when all blocks are pinned (ie refcount>0). This is consistent with the current behavior. The cache's insert function never fails. I spent lots of time trying to make table_reader and other places work with the insert which might failed. It turned out to be pretty hard. It might really destabilize some customers, so finally, I decided against doing this.
table_cache_remove_scan_count_limit option will be unneeded after this change, but I will remove it in the following diff, if this one gets approved
Test Plan: Ran tests, made sure they pass
Reviewers: sdong, ljin
Differential Revision: https://reviews.facebook.net/D25503
2014-10-21 20:49:13 +02:00
|
|
|
// is freed or the lru list is empty
|
2015-04-24 23:12:58 +02:00
|
|
|
EvictFromLRU(charge, &last_reference_list);
|
Modifed the LRU cache eviction code so that it doesn't evict blocks which have exteranl references
Summary:
Currently, blocks which have more than one reference (ie referenced by something other than cache itself) are evicted from cache. This doesn't make much sense:
- blocks are still in RAM, so the RAM usage reported by the cache is incorrect
- if the same block is needed by another iterator, it will be loaded and decompressed again
This diff changes the reference counting scheme a bit. Previously, if the cache contained the block, this was accounted for in its refcount. After this change, the refcount is only used to track external references. There is a boolean flag which indicates whether or not the block is contained in the cache.
This diff also changes how LRU list is used. Previously, both hashtable and the LRU list contained all blocks. After this change, the LRU list contains blocks with the refcount==0, ie those which can be evicted from the cache.
Note that this change still allows for cache to grow beyond its capacity. This happens when all blocks are pinned (ie refcount>0). This is consistent with the current behavior. The cache's insert function never fails. I spent lots of time trying to make table_reader and other places work with the insert which might failed. It turned out to be pretty hard. It might really destabilize some customers, so finally, I decided against doing this.
table_cache_remove_scan_count_limit option will be unneeded after this change, but I will remove it in the following diff, if this one gets approved
Test Plan: Ran tests, made sure they pass
Reviewers: sdong, ljin
Differential Revision: https://reviews.facebook.net/D25503
2014-10-21 20:49:13 +02:00
|
|
|
|
2016-08-23 22:53:49 +02:00
|
|
|
if (usage_ - lru_usage_ + charge > capacity_ &&
|
|
|
|
(strict_capacity_limit_ || handle == nullptr)) {
|
2016-03-11 02:35:19 +01:00
|
|
|
if (handle == nullptr) {
|
2016-08-23 22:53:49 +02:00
|
|
|
// Don't insert the entry but still return ok, as if the entry inserted
|
|
|
|
// into cache and get evicted immediately.
|
2016-03-11 02:35:19 +01:00
|
|
|
last_reference_list.push_back(e);
|
|
|
|
} else {
|
|
|
|
delete[] reinterpret_cast<char*>(e);
|
|
|
|
*handle = nullptr;
|
2016-08-23 22:53:49 +02:00
|
|
|
s = Status::Incomplete("Insert failed due to LRU cache being full.");
|
2016-03-11 02:35:19 +01:00
|
|
|
}
|
|
|
|
} else {
|
|
|
|
// insert into the cache
|
|
|
|
// note that the cache might get larger than its capacity if not enough
|
|
|
|
// space was freed
|
|
|
|
LRUHandle* old = table_.Insert(e);
|
|
|
|
usage_ += e->charge;
|
|
|
|
if (old != nullptr) {
|
2016-08-20 01:43:31 +02:00
|
|
|
old->SetInCache(false);
|
2016-03-11 02:35:19 +01:00
|
|
|
if (Unref(old)) {
|
|
|
|
usage_ -= old->charge;
|
|
|
|
// old is on LRU because it's in cache and its reference count
|
|
|
|
// was just 1 (Unref returned 0)
|
|
|
|
LRU_Remove(old);
|
|
|
|
last_reference_list.push_back(old);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (handle == nullptr) {
|
2016-08-20 01:43:31 +02:00
|
|
|
LRU_Insert(e);
|
2016-03-11 02:35:19 +01:00
|
|
|
} else {
|
|
|
|
*handle = reinterpret_cast<Cache::Handle*>(e);
|
2013-10-08 00:37:40 +02:00
|
|
|
}
|
2016-03-11 02:35:19 +01:00
|
|
|
s = Status::OK();
|
2013-10-08 00:37:40 +02:00
|
|
|
}
|
2011-03-18 23:37:00 +01:00
|
|
|
}
|
|
|
|
|
2013-10-08 00:37:40 +02:00
|
|
|
// we free the entries here outside of mutex for
|
|
|
|
// performance reasons
|
|
|
|
for (auto entry : last_reference_list) {
|
Modifed the LRU cache eviction code so that it doesn't evict blocks which have exteranl references
Summary:
Currently, blocks which have more than one reference (ie referenced by something other than cache itself) are evicted from cache. This doesn't make much sense:
- blocks are still in RAM, so the RAM usage reported by the cache is incorrect
- if the same block is needed by another iterator, it will be loaded and decompressed again
This diff changes the reference counting scheme a bit. Previously, if the cache contained the block, this was accounted for in its refcount. After this change, the refcount is only used to track external references. There is a boolean flag which indicates whether or not the block is contained in the cache.
This diff also changes how LRU list is used. Previously, both hashtable and the LRU list contained all blocks. After this change, the LRU list contains blocks with the refcount==0, ie those which can be evicted from the cache.
Note that this change still allows for cache to grow beyond its capacity. This happens when all blocks are pinned (ie refcount>0). This is consistent with the current behavior. The cache's insert function never fails. I spent lots of time trying to make table_reader and other places work with the insert which might failed. It turned out to be pretty hard. It might really destabilize some customers, so finally, I decided against doing this.
table_cache_remove_scan_count_limit option will be unneeded after this change, but I will remove it in the following diff, if this one gets approved
Test Plan: Ran tests, made sure they pass
Reviewers: sdong, ljin
Differential Revision: https://reviews.facebook.net/D25503
2014-10-21 20:49:13 +02:00
|
|
|
entry->Free();
|
2011-03-18 23:37:00 +01:00
|
|
|
}
|
|
|
|
|
2016-03-11 02:35:19 +01:00
|
|
|
return s;
|
2011-03-18 23:37:00 +01:00
|
|
|
}
|
|
|
|
|
2016-07-15 19:41:36 +02:00
|
|
|
void LRUCacheShard::Erase(const Slice& key, uint32_t hash) {
|
2013-10-08 00:37:40 +02:00
|
|
|
LRUHandle* e;
|
|
|
|
bool last_reference = false;
|
|
|
|
{
|
|
|
|
MutexLock l(&mutex_);
|
|
|
|
e = table_.Remove(key, hash);
|
|
|
|
if (e != nullptr) {
|
|
|
|
last_reference = Unref(e);
|
Modifed the LRU cache eviction code so that it doesn't evict blocks which have exteranl references
Summary:
Currently, blocks which have more than one reference (ie referenced by something other than cache itself) are evicted from cache. This doesn't make much sense:
- blocks are still in RAM, so the RAM usage reported by the cache is incorrect
- if the same block is needed by another iterator, it will be loaded and decompressed again
This diff changes the reference counting scheme a bit. Previously, if the cache contained the block, this was accounted for in its refcount. After this change, the refcount is only used to track external references. There is a boolean flag which indicates whether or not the block is contained in the cache.
This diff also changes how LRU list is used. Previously, both hashtable and the LRU list contained all blocks. After this change, the LRU list contains blocks with the refcount==0, ie those which can be evicted from the cache.
Note that this change still allows for cache to grow beyond its capacity. This happens when all blocks are pinned (ie refcount>0). This is consistent with the current behavior. The cache's insert function never fails. I spent lots of time trying to make table_reader and other places work with the insert which might failed. It turned out to be pretty hard. It might really destabilize some customers, so finally, I decided against doing this.
table_cache_remove_scan_count_limit option will be unneeded after this change, but I will remove it in the following diff, if this one gets approved
Test Plan: Ran tests, made sure they pass
Reviewers: sdong, ljin
Differential Revision: https://reviews.facebook.net/D25503
2014-10-21 20:49:13 +02:00
|
|
|
if (last_reference) {
|
|
|
|
usage_ -= e->charge;
|
|
|
|
}
|
2016-08-20 01:43:31 +02:00
|
|
|
if (last_reference && e->InCache()) {
|
Modifed the LRU cache eviction code so that it doesn't evict blocks which have exteranl references
Summary:
Currently, blocks which have more than one reference (ie referenced by something other than cache itself) are evicted from cache. This doesn't make much sense:
- blocks are still in RAM, so the RAM usage reported by the cache is incorrect
- if the same block is needed by another iterator, it will be loaded and decompressed again
This diff changes the reference counting scheme a bit. Previously, if the cache contained the block, this was accounted for in its refcount. After this change, the refcount is only used to track external references. There is a boolean flag which indicates whether or not the block is contained in the cache.
This diff also changes how LRU list is used. Previously, both hashtable and the LRU list contained all blocks. After this change, the LRU list contains blocks with the refcount==0, ie those which can be evicted from the cache.
Note that this change still allows for cache to grow beyond its capacity. This happens when all blocks are pinned (ie refcount>0). This is consistent with the current behavior. The cache's insert function never fails. I spent lots of time trying to make table_reader and other places work with the insert which might failed. It turned out to be pretty hard. It might really destabilize some customers, so finally, I decided against doing this.
table_cache_remove_scan_count_limit option will be unneeded after this change, but I will remove it in the following diff, if this one gets approved
Test Plan: Ran tests, made sure they pass
Reviewers: sdong, ljin
Differential Revision: https://reviews.facebook.net/D25503
2014-10-21 20:49:13 +02:00
|
|
|
LRU_Remove(e);
|
|
|
|
}
|
2016-08-20 01:43:31 +02:00
|
|
|
e->SetInCache(false);
|
2013-10-08 00:37:40 +02:00
|
|
|
}
|
|
|
|
}
|
Modifed the LRU cache eviction code so that it doesn't evict blocks which have exteranl references
Summary:
Currently, blocks which have more than one reference (ie referenced by something other than cache itself) are evicted from cache. This doesn't make much sense:
- blocks are still in RAM, so the RAM usage reported by the cache is incorrect
- if the same block is needed by another iterator, it will be loaded and decompressed again
This diff changes the reference counting scheme a bit. Previously, if the cache contained the block, this was accounted for in its refcount. After this change, the refcount is only used to track external references. There is a boolean flag which indicates whether or not the block is contained in the cache.
This diff also changes how LRU list is used. Previously, both hashtable and the LRU list contained all blocks. After this change, the LRU list contains blocks with the refcount==0, ie those which can be evicted from the cache.
Note that this change still allows for cache to grow beyond its capacity. This happens when all blocks are pinned (ie refcount>0). This is consistent with the current behavior. The cache's insert function never fails. I spent lots of time trying to make table_reader and other places work with the insert which might failed. It turned out to be pretty hard. It might really destabilize some customers, so finally, I decided against doing this.
table_cache_remove_scan_count_limit option will be unneeded after this change, but I will remove it in the following diff, if this one gets approved
Test Plan: Ran tests, made sure they pass
Reviewers: sdong, ljin
Differential Revision: https://reviews.facebook.net/D25503
2014-10-21 20:49:13 +02:00
|
|
|
|
2013-10-08 00:37:40 +02:00
|
|
|
// mutex not held here
|
|
|
|
// last_reference will only be true if e != nullptr
|
|
|
|
if (last_reference) {
|
Modifed the LRU cache eviction code so that it doesn't evict blocks which have exteranl references
Summary:
Currently, blocks which have more than one reference (ie referenced by something other than cache itself) are evicted from cache. This doesn't make much sense:
- blocks are still in RAM, so the RAM usage reported by the cache is incorrect
- if the same block is needed by another iterator, it will be loaded and decompressed again
This diff changes the reference counting scheme a bit. Previously, if the cache contained the block, this was accounted for in its refcount. After this change, the refcount is only used to track external references. There is a boolean flag which indicates whether or not the block is contained in the cache.
This diff also changes how LRU list is used. Previously, both hashtable and the LRU list contained all blocks. After this change, the LRU list contains blocks with the refcount==0, ie those which can be evicted from the cache.
Note that this change still allows for cache to grow beyond its capacity. This happens when all blocks are pinned (ie refcount>0). This is consistent with the current behavior. The cache's insert function never fails. I spent lots of time trying to make table_reader and other places work with the insert which might failed. It turned out to be pretty hard. It might really destabilize some customers, so finally, I decided against doing this.
table_cache_remove_scan_count_limit option will be unneeded after this change, but I will remove it in the following diff, if this one gets approved
Test Plan: Ran tests, made sure they pass
Reviewers: sdong, ljin
Differential Revision: https://reviews.facebook.net/D25503
2014-10-21 20:49:13 +02:00
|
|
|
e->Free();
|
2011-03-18 23:37:00 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-08-16 23:43:41 +02:00
|
|
|
size_t LRUCacheShard::GetUsage() const {
|
|
|
|
MutexLock l(&mutex_);
|
|
|
|
return usage_;
|
|
|
|
}
|
|
|
|
|
|
|
|
size_t LRUCacheShard::GetPinnedUsage() const {
|
|
|
|
MutexLock l(&mutex_);
|
|
|
|
assert(usage_ >= lru_usage_);
|
|
|
|
return usage_ - lru_usage_;
|
|
|
|
}
|
|
|
|
|
2016-08-23 22:44:13 +02:00
|
|
|
LRUCache::LRUCache(size_t capacity, int num_shard_bits,
|
|
|
|
bool strict_capacity_limit, double high_pri_pool_ratio)
|
|
|
|
: ShardedCache(capacity, num_shard_bits, strict_capacity_limit) {
|
|
|
|
int num_shards = 1 << num_shard_bits;
|
|
|
|
shards_ = new LRUCacheShard[num_shards];
|
|
|
|
SetCapacity(capacity);
|
|
|
|
SetStrictCapacityLimit(strict_capacity_limit);
|
|
|
|
for (int i = 0; i < num_shards; i++) {
|
|
|
|
shards_[i].SetHighPriorityPoolRatio(high_pri_pool_ratio);
|
2011-08-22 23:08:51 +02:00
|
|
|
}
|
2016-08-23 22:44:13 +02:00
|
|
|
}
|
2011-08-22 23:08:51 +02:00
|
|
|
|
2016-08-23 22:44:13 +02:00
|
|
|
LRUCache::~LRUCache() { delete[] shards_; }
|
2014-01-28 19:35:48 +01:00
|
|
|
|
2016-08-23 22:44:13 +02:00
|
|
|
CacheShard* LRUCache::GetShard(int shard) {
|
|
|
|
return reinterpret_cast<CacheShard*>(&shards_[shard]);
|
|
|
|
}
|
2016-03-11 02:35:19 +01:00
|
|
|
|
2016-08-23 22:44:13 +02:00
|
|
|
const CacheShard* LRUCache::GetShard(int shard) const {
|
|
|
|
return reinterpret_cast<CacheShard*>(&shards_[shard]);
|
|
|
|
}
|
2015-10-08 00:17:20 +02:00
|
|
|
|
2016-08-23 22:44:13 +02:00
|
|
|
void* LRUCache::Value(Handle* handle) {
|
|
|
|
return reinterpret_cast<const LRUHandle*>(handle)->value;
|
|
|
|
}
|
2015-10-08 00:17:20 +02:00
|
|
|
|
2016-08-23 22:44:13 +02:00
|
|
|
size_t LRUCache::GetCharge(Handle* handle) const {
|
|
|
|
return reinterpret_cast<const LRUHandle*>(handle)->charge;
|
|
|
|
}
|
2014-01-28 19:35:48 +01:00
|
|
|
|
2016-08-23 22:44:13 +02:00
|
|
|
uint32_t LRUCache::GetHash(Handle* handle) const {
|
|
|
|
return reinterpret_cast<const LRUHandle*>(handle)->hash;
|
|
|
|
}
|
2014-05-02 22:24:04 +02:00
|
|
|
|
2016-08-23 22:44:13 +02:00
|
|
|
void LRUCache::DisownData() { shards_ = nullptr; }
|
2011-03-18 23:37:00 +01:00
|
|
|
|
2016-05-24 08:35:23 +02:00
|
|
|
std::shared_ptr<Cache> NewLRUCache(size_t capacity, int num_shard_bits,
|
2016-08-20 01:43:31 +02:00
|
|
|
bool strict_capacity_limit,
|
|
|
|
double high_pri_pool_ratio) {
|
2013-12-11 01:21:49 +01:00
|
|
|
if (num_shard_bits >= 20) {
|
2013-03-01 03:04:58 +01:00
|
|
|
return nullptr; // the cache cannot be sharded into too many fine pieces
|
2012-08-29 18:47:53 +02:00
|
|
|
}
|
2016-08-20 01:43:31 +02:00
|
|
|
if (high_pri_pool_ratio < 0.0 || high_pri_pool_ratio > 1.0) {
|
|
|
|
// invalid high_pri_pool_ratio
|
|
|
|
return nullptr;
|
|
|
|
}
|
2016-07-15 19:41:36 +02:00
|
|
|
return std::make_shared<LRUCache>(capacity, num_shard_bits,
|
2016-08-20 01:43:31 +02:00
|
|
|
strict_capacity_limit, high_pri_pool_ratio);
|
2012-05-17 02:22:33 +02:00
|
|
|
}
|
|
|
|
|
2013-10-04 06:49:15 +02:00
|
|
|
} // namespace rocksdb
|