[PATCH] D119784: [Symbolize] LRU cache binaries in llvm-symbolizer.
Daniel Thornburgh via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Fri Feb 18 15:40:19 PST 2022
mysterymath added a comment.
> Do you have some performance numbers? What if we didn't cache/had a cache size of 0? (does the caching logic buy us enough performance to justify it)
I did some poking around, and it looks like restarting the job after every request was tried as a workaround.
This choked on large binaries, and they had to change to restart-every-n requests.
I took a large debug binary, Clang, and symbolized 100 random symbols from it.
Zero-size LRU:
real 4m44.289s
user 4m27.506s
sys 0m16.720s
No LRU, flush after each request:
real 4m41.313s
user 4m24.575s
sys 0m16.666s
Unbounded LRU:
real 0m4.309s
user 0m3.842s
sys 0m0.471s
HEAD:
real 0m4.505s
user 0m3.982s
sys 0m0.526s
Conversely, we can look at how much overhead the LRU order maintenance adds to 100000 very easily cacheable requests (lookup `main` in `int main(void){return 0;}`).
Unbounded LRU:
real 0m0.421s
user 0m0.305s
sys 0m0.120s
HEAD:
real 0m0.410s
user 0m0.334s
sys 0m0.079s
Looking at the zero-size LRU, I think we'd probably want cache sizes to be soft.
If a large binary is symbolized, and the binary is over the cap, then it's guaranteed to be evicted from the cache after each request, even though this doesn't lower the peak memory usage of the binary.
Instead, we can inflate the cap to the size of the largest individual binary that has been symbolized; this is the high water mark of memory usage overall.
This would let us pick a relatively low default cap, say 500MiB, without harming performance when symbolizing larger binaries.
Also, I realize that these examples are synthetic, but they should help characterize the edge case behaviors at least. I'll post back with a real example from system logs soon.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D119784/new/
https://reviews.llvm.org/D119784
More information about the llvm-commits
mailing list