deardeng commented on code in PR #67313:
URL: https://github.com/apache/doris/pull/67313#discussion_r3888545315
##########
be/src/io/cache/block_file_cache.cpp:
##########
@@ -2577,6 +2569,15 @@ BlockFileCache::get_hot_blocks_meta(const
UInt128Wrapper& hash) const {
bool BlockFileCache::try_reserve_during_async_load(size_t size,
std::lock_guard<std::mutex>& cache_lock) {
+ size_t evict_target =
Review Comment:
Confirmed: load_cache_info_into_memory_from_db()/from_fs() and
load_blocks_directly_unlocked() call add_cell(..., DOWNLOADED) directly
(fs_file_cache_storage.cpp:818, :1007, :1179) and never go through
try_reserve(). But those blocks already exist on disk; the loader's job is to
register physical state into memory. Refusing admission there would not save
any space — it would orphan the files: bytes on disk with no cell, no LRU
entry, and therefore nothing that can ever evict them. Being transiently over
capacity is strictly better than leaking disk.
This is also not something this PR changes. The loader has never consulted
_capacity, and the reset_capacity() assignment that this PR removed never gated
it either, because the loader does not call try_reserve() at all. Shrinking
mid-load leaves _cur_cache_size above _capacity on master exactly as it does
here.
And the state converges on its own once loading completes: try_reserve()
then takes the normal branch (cur_cache_size + size - removed_size >
_capacity), and enable_evict_file_cache_in_advance defaults to true, so
check_need_evict_cache_in_advance() computes size_percentage = _cur_cache_size
* 100 / _capacity above 100 and drives eviction from the monitor loop without
waiting for a miss.
Routing metadata restoration through admission control, or deferring
publication until load completes, is a redesign of cache loading with real
consequences for restart warm-up. If it is worth doing it deserves its own PR
and its own discussion, not a fold-in to a hysteresis fix.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
