Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make Cache into a Customizable Object #8998

Open
wants to merge 24 commits into
base: main
Choose a base branch
from

Conversation

mrambacher
Copy link
Contributor

@mrambacher mrambacher commented Oct 8, 2021

  • Make Cache into a Customizable Object and add appropriate methods
  • Add ability to configure cache via options
  • Add ability to create a cache from a URI to db_bench and cache_bench

@@ -741,7 +787,7 @@ void LRUCache::WaitAll(std::vector<Handle*>& handles) {
}
sec_handles.emplace_back(lru_handle->sec_handle);
}
secondary_cache_->WaitAll(sec_handles);
options_.secondary_cache->WaitAll(sec_handles);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think there are more places that we use "secondary_cache_->" for lookup and insertion.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Those are done within the shard, which has a secondary_cache_ element.

@@ -474,8 +473,8 @@ class LRUCache

private:
LRUCacheShard* shards_ = nullptr;
LRUCacheOptions options_;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I may prefer to keep the secondary_cache_ pointer here. using options_.secondary_cache is hard to understand and maybe in the future, we can replace the secondary_cache_ on the fly (e.g., from local secondary to the remote secondary)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Whether or not it is in the LRUCacheOptions or an independent argument, the rules would be the same for what you are suggesting. As an LRUCacheOption member, it is easier to keep it with the rest of the options and treat it the same as everything else.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since the place to pass in the SecondaryCache might change, we may keep using options_.secondary_cache for now.

@@ -47,7 +48,19 @@ enum CacheMetadataChargePolicy {
const CacheMetadataChargePolicy kDefaultCacheMetadataChargePolicy =
kFullChargeCacheMetadata;

struct LRUCacheOptions {
struct CacheOptions {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure, this CacheOptions is general enough. Maybe some other cache will not use shard? May need some discussion here.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree that at least some of these options are implementation-specific. After #9126 I'm likely to work on a new clock cache that does not use sharding, and might not support strict_capacity_limit.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed the CacheOptions

// Caveat: when the cache is used as block cache, the memory allocator is
// ignored when dealing with compression libraries that allocate memory
// internally (currently only XPRESS).
std::shared_ptr<MemoryAllocator> memory_allocator;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the reason to move it into the CacheOptions structure? Do we pair the memory_allocator with a certain option?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It was already in the LRUCacheOptions.

GetShard(s)->SetStrictCapacityLimit(strict_capacity_limit);
Status ShardedCache::ValidateOptions(const DBOptions& db_opts,
const ColumnFamilyOptions& cf_opts) const {
if (IsMutable()) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why we need "IsMutable()" as a member function for cache? It is unclear to me what it means: the size is mutable? or the configuration is mutable?

options_.num_shard_bits = GetDefaultCacheShardBits(options_.capacity);
}
Status s = ShardedCache::PrepareOptions(config_options);
if (s.ok()) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Start from here, I do not think it belongs to the function of "PrepareOptions". We may need another function for initiation and call it after "PrepareOptions" in "NewLRUCache"

@@ -474,8 +482,7 @@ class LRUCache

private:
LRUCacheShard* shards_ = nullptr;
int num_shards_ = 0;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why we remove this member?

options_.num_shard_bits = GetDefaultCacheShardBits(options_.capacity);
}
s = ShardedCache::PrepareOptions(config_options);
if (s.ok()) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is the same here. I prefer not to put them in "PrepareOptions"

@@ -384,9 +387,7 @@ class Cache {
// Prerequisite: no entry is referenced.
virtual void EraseUnRefEntries() = 0;

virtual std::string GetPrintableOptions() const { return ""; }
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we keep this interface even we can call Customizable function to achieve the same?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is already there (via Configurable)

@@ -209,12 +213,12 @@ class Cache {
using CreateCallback = std::function<Status(void* buf, size_t size,
void** out_obj, size_t* charge)>;

Cache(std::shared_ptr<MemoryAllocator> allocator = nullptr)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Move the memory_allocator out of the abstract class "Cache" and use it as a member of cache option looks good to me. But one thing I'm not sure is, if it will make some interface compatibility issues for some users how developed their own cache?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It goes both ways. If there is a non-standard Cache that was expecting/relying on the memory allocator, then this will change that class. OTOH, if there is a cache that does not use the RocksDB allocators (like potentially CacheLib), the implementation would not have to provide one.

@facebook-github-bot
Copy link
Contributor

@mrambacher has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator.

@facebook-github-bot
Copy link
Contributor

@mrambacher has updated the pull request. You must reimport the pull request before landing.

@mrambacher mrambacher changed the title Make Cache into a Customizable Managed Object Make Cache into a Customizable Object May 31, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants