-
Notifications
You must be signed in to change notification settings - Fork 429
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
[Config Change] Stylus LRU cache with bytes capacity instead of number of entries capacity #2595
base: master
Are you sure you want to change the base?
Conversation
2961c11
to
b90c32a
Compare
@@ -75,7 +75,7 @@ var DefaultCachingConfig = CachingConfig{ | |||
SnapshotRestoreGasLimit: 300_000_000_000, | |||
MaxNumberOfBlocksToSkipStateSaving: 0, | |||
MaxAmountOfGasToSkipStateSaving: 0, | |||
StylusLRUCache: 256, | |||
StylusLRUCacheCapacity: 256, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suggestions on the default value?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am fine with 256 for now. If we frequently run out, we can change it in a later PR.
e91655c
to
165d484
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
realised I'm sitting on these Pending comments for a while .. sorry
arbitrator/stylus/src/cache.rs
Outdated
fn weight(&self, _key: &CacheKey, val: &CacheItem) -> usize { | ||
// clru defines that each entry consumes (weight + 1) of the cache capacity. | ||
// We subtract 1 since we only want to use the weight as the size of the entry. | ||
val.asm_size_estimate_bytes.saturating_sub(1) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually - a more exact number would be something like.. asm_size_estimate + 64/128
Since you are counting bytes, and every entry in the cache has overhead of the cache-key, cacheItem and some internal pointers. Exact number is not too important.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added the 128 bytes to account for overheads that you mentioned :).
I kept taking into account that clru defines that each entry consumes (weight + 1) of the cache capacity though.
This simplifies tests that checks the expected cache size.
let count = cache.lru.len(); | ||
let metrics = LruCacheMetrics { | ||
// add 1 to each entry to account that we subtracted 1 in the weight calculation | ||
size_bytes: (cache.lru.weight() + count).try_into().unwrap(), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Normal entry is order of magnitude of 100,000. a few bytes per entry isn't worth fussing over (I'd go with weight = deser_size + 128 and return lru.weight() from here)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added the 128 bytes to account for overheads that you mentioned :).
I kept taking into account that clru defines that each entry consumes (weight + 1) of the cache capacity though.
This simplifies tests that checks the expected cache size.
/// Clears lru cache. | ||
/// Only used for testing purposes. | ||
#[no_mangle] | ||
pub extern "C" fn stylus_clear_lru_cache() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
wont stylus_set_cache_lru_capacity(0) and then resize-again work?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nope :(, capacity must be non zero https://docs.rs/clru/0.6.2/clru/struct.CLruCache.html#method.resize
@@ -7,7 +7,7 @@ | |||
package programs | |||
|
|||
/* | |||
#cgo CFLAGS: -g -Wall -I../../target/include/ | |||
#cgo CFLAGS: -g -I../../target/include/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
go doesn't handle it well: https://stackoverflow.com/questions/56633817/warning-unused-variable-cgo-a.
With it the following warning was being generated without need:
cgo-gcc-prolog: In function ‘_cgo_80afc8d9354c_Cfunc_stylus_clear_lru_cache’:
cgo-gcc-prolog:139:49: warning: unused variable ‘_cgo_a’ [-Wunused-variable]
@@ -75,7 +75,7 @@ var DefaultCachingConfig = CachingConfig{ | |||
SnapshotRestoreGasLimit: 300_000_000_000, | |||
MaxNumberOfBlocksToSkipStateSaving: 0, | |||
MaxAmountOfGasToSkipStateSaving: 0, | |||
StylusLRUCache: 256, | |||
StylusLRUCacheCapacity: 256, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am fine with 256 for now. If we frequently run out, we can change it in a later PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
…us LRU cache entry
b514e73
to
f144eb1
Compare
Resolves NIT-2698
Stylus LRU cache with bytes capacity instead of number of entries capacity.
It infers the size of each entry by computing the number of bytes related to the serialized wasm module.
This PR also removes
-Wall
from cgo CFLAGS.go doesn't handle it well: https://stackoverflow.com/questions/56633817/warning-unused-variable-cgo-a.
With it the following warning was being generated without need: