Add a reliable way to tell if per CPU or per thread caching is being used

[SrivastavaAnubhav]

When running on Centos7, which is on linux kernel 3.10 and thus shouldn't have RSEQ support, MallocExtension::PerCpuCachesActive() returns true, even though per-thread caches are being used (this can be verified by checking the sizes of the per-cpu and per-thread freelists in DumpStats). Either PerCpuCachesActive should return false here, or there should be some other way of checking whether per cpu caching or per thread caching is being used.

[SrivastavaAnubhav]

A somewhat related followup question: If I compile on Centos 7 (which does not have RSEQ) and run on Centos 8 (which does have RSEQ), will per-cpu caching be used?

[ckennelly]

TCMalloc tries to use per-CPU caches if rseq is available.

That said, it is a little odd that PerCpuCachesActive is returning true on a platform where rseq is unavailable. I'm not sure if it'd be possible to run one of TCMalloc's tests--nearly any should do--under gdb to step through the flow when the CPU caches try to initialize.

[SrivastavaAnubhav]

TCMalloc tries to use per-CPU caches if rseq is available.

Just to confirm: is this a runtime check? Also, it's not configurable, right?

[ckennelly]

Yes, it's a runtime check (for the availability of the syscall).

We have a target tcmalloc_deprecated_perthread, but it is meant for testing (by forcing per-cpu caches off) more than anything.