-
Notifications
You must be signed in to change notification settings - Fork 36.2k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge #18637: coins: allow cache resize after init
f19fdd4 test: add test for CChainState::ResizeCoinsCaches() (James O'Beirne) 8ac3ef4 add ChainstateManager::MaybeRebalanceCaches() (James O'Beirne) f36aaa6 Add CChainState::ResizeCoinsCaches (James O'Beirne) b223111 txdb: add CCoinsViewDB::ChangeCacheSize (James O'Beirne) Pull request description: This is part of the [assumeutxo project](https://github.com/bitcoin/bitcoin/projects/11): Parent PR: #15606 Issue: #15605 Specification: https://github.com/jamesob/assumeutxo-docs/tree/master/proposal --- In the assumeutxo implementation draft (#15056), once a UTXO snapshot is loaded, a new chainstate object is created after initialization. This means that we have to reclaim some of the cache that we've allocated to the original chainstate (per `dbcache=`) to repurpose for the snapshot chainstate. Furthermore, it makes sense to have different cache allocations depending on which chainstate is more active. While the snapshot chainstate is working to get to the network tip (and the background validation chainstate is idle), it makes sense that the snapshot chainstate should have the majority of cache allocation. And contrariwise once the snapshot has reached network tip, most of the cache should be given to the background validation chainstate. This set of changes (detailed in the commit messages) allows us to dynamically resize the various coins caches. None of the functionality introduced here is used at the moment, but will be in the next AU PR (which introduces `ActivateSnapshot`). `ChainstateManager::MaybeRebalanceCaches()` defines the (somewhat normative) cache allocations between the snapshot and background validation chainstates. I'd be interested in feedback if anyone has thoughts on the proportions I've set there. ACKs for top commit: ajtowns: weak utACK f19fdd4 -- didn't find any major problems, but not super confident that I didn't miss anything fjahr: Code review ACK f19fdd4 ryanofsky: Code review ACK f19fdd4. Only change since last review is constructor cleanup (no change in behavior). I think the suggestions here from ajtowns and others are good, but shouldn't delay merging the PR (and hold up assumeutxo) Tree-SHA512: fffb7847fb6993dd4a1a41cf11179b211b0b20b7eb5f7cf6266442136bfe9d43b830bbefcafd475bfd4af273f5573500594aa41fff03e0ed5c2a1e8562ff9269
- Loading branch information
Showing
12 changed files
with
285 additions
and
33 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,76 @@ | ||
// Copyright (c) 2020 The Bitcoin Core developers | ||
// Distributed under the MIT software license, see the accompanying | ||
// file COPYING or http://www.opensource.org/licenses/mit-license.php. | ||
// | ||
#include <random.h> | ||
#include <uint256.h> | ||
#include <consensus/validation.h> | ||
#include <sync.h> | ||
#include <test/util/setup_common.h> | ||
#include <validation.h> | ||
|
||
#include <vector> | ||
|
||
#include <boost/test/unit_test.hpp> | ||
|
||
BOOST_FIXTURE_TEST_SUITE(validation_chainstate_tests, TestingSetup) | ||
|
||
//! Test resizing coins-related CChainState caches during runtime. | ||
//! | ||
BOOST_AUTO_TEST_CASE(validation_chainstate_resize_caches) | ||
{ | ||
ChainstateManager manager; | ||
|
||
//! Create and add a Coin with DynamicMemoryUsage of 80 bytes to the given view. | ||
auto add_coin = [](CCoinsViewCache& coins_view) -> COutPoint { | ||
Coin newcoin; | ||
uint256 txid = InsecureRand256(); | ||
COutPoint outp{txid, 0}; | ||
newcoin.nHeight = 1; | ||
newcoin.out.nValue = InsecureRand32(); | ||
newcoin.out.scriptPubKey.assign((uint32_t)56, 1); | ||
coins_view.AddCoin(outp, std::move(newcoin), false); | ||
|
||
return outp; | ||
}; | ||
|
||
ENTER_CRITICAL_SECTION(cs_main); | ||
CChainState& c1 = manager.InitializeChainstate(); | ||
LEAVE_CRITICAL_SECTION(cs_main); | ||
c1.InitCoinsDB( | ||
/* cache_size_bytes */ 1 << 23, /* in_memory */ true, /* should_wipe */ false); | ||
WITH_LOCK(::cs_main, c1.InitCoinsCache(1 << 23)); | ||
|
||
// Add a coin to the in-memory cache, upsize once, then downsize. | ||
{ | ||
LOCK(::cs_main); | ||
auto outpoint = add_coin(c1.CoinsTip()); | ||
|
||
// Set a meaningless bestblock value in the coinsview cache - otherwise we won't | ||
// flush during ResizecoinsCaches() and will subsequently hit an assertion. | ||
c1.CoinsTip().SetBestBlock(InsecureRand256()); | ||
|
||
BOOST_CHECK(c1.CoinsTip().HaveCoinInCache(outpoint)); | ||
|
||
c1.ResizeCoinsCaches( | ||
1 << 24, // upsizing the coinsview cache | ||
1 << 22 // downsizing the coinsdb cache | ||
); | ||
|
||
// View should still have the coin cached, since we haven't destructed the cache on upsize. | ||
BOOST_CHECK(c1.CoinsTip().HaveCoinInCache(outpoint)); | ||
|
||
c1.ResizeCoinsCaches( | ||
1 << 22, // downsizing the coinsview cache | ||
1 << 23 // upsizing the coinsdb cache | ||
); | ||
|
||
// The view cache should be empty since we had to destruct to downsize. | ||
BOOST_CHECK(!c1.CoinsTip().HaveCoinInCache(outpoint)); | ||
} | ||
|
||
// Avoid triggering the address sanitizer. | ||
WITH_LOCK(::cs_main, manager.Unload()); | ||
} | ||
|
||
BOOST_AUTO_TEST_SUITE_END() |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.