[PATCH] D93731: scudo: Support memory tagging in the secondary allocator.

Peter Collingbourne via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Feb 12 20:52:12 PST 2021


pcc added a comment.

In D93731#2558250 <https://reviews.llvm.org/D93731#2558250>, @cferris wrote:

> I reran the benchmarks and everything looks much better. There were only a few micro-benchmarks that showed decreases that are worrying. For example:
>
> 32 bit:
>
> BM_stdlib_calloc_free_decay1/131072 decreased by about 18%
> BM_stdlib_calloc_free_default/131072 decreased by about 10%
>
> Various multi-alloc (malloc_forty, malloc_multiple_8192 ones) benchmarks decreased by about 10%.
>
> 64 bit:
>
> BM_stdlib_malloc_free_decay1/16384 decreased by about 7%.
> BM_stdlib_malloc_free_default/16384 decreased by about 7%.
> BM_stdlib_calloc_free_decay1/16384 decreased by about 7%.
> BM_stdlib_calloc_free_default/131072 decreased by about 5%.
>
> And then a few of malloc_forty ones decreased by about 12%.
>
> The malloc_forty and malloc_multiple do not really ever correlate with real world code, so I don't think they matter. The larger allocations performance decreases are worrying. Does it make sense that we would see this decrease?
>
> Nothing else showed any really big issues, which probably means that there aren't that many traces that do large allocations that would cause large performance degradation.
>
> I'm inclined to say this is fine if the degradation makes sense.

I think I've managed to fix the performance regressions with the latest update.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D93731/new/

https://reviews.llvm.org/D93731



More information about the llvm-commits mailing list