Skip to content
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.

Sign up for GitHub

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

Jump to bottom

[scudo] Fix the logic of MaxAllowedFragmentedPages #107927

Merged
merged 3 commits into from
Sep 11, 2024
Merged

[scudo] Fix the logic of MaxAllowedFragmentedPages #107927

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
d9b12ee
[scudo] Fix the logic of MaxAllowedFragmentedPages
ChiaHungDuan Sep 9, 2024
6e3a54a
Add a DCHECK and some comments
ChiaHungDuan Sep 10, 2024
ac1fded
grammar fix
ChiaHungDuan Sep 10, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
25 changes: 17 additions & 8 deletions compiler-rt/lib/scudo/standalone/secondary.h
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -72,13 +72,16 @@ namespace {
struct CachedBlock {
static constexpr u16 CacheIndexMax = UINT16_MAX;
static constexpr u16 InvalidEntry = CacheIndexMax;
// * MaxReleasedCachePages default is currently 4
// - We arrived at this value after noticing that mapping
// in larger memory regions performs better than releasing
// memory and forcing a cache hit. According to the data,
// it suggests that beyond 4 pages, the release execution time is
// longer than the map execution time. In this way, the default
// is dependent on the platform.
// We allow a certain amount of fragmentation and part of the fragmented bytes
// will be released by `releaseAndZeroPagesToOS()`. This increases the chance
// of cache hit rate and reduces the overhead to the RSS at the same time. See
// more details in the `MapAllocatorCache::retrieve()` section.
//
// We arrived at this default value after noticing that mapping in larger
// memory regions performs better than releasing memory and forcing a cache
// hit. According to the data, it suggests that beyond 4 pages, the release
// execution time is longer than the map execution time. In this way,
// the default is dependent on the platform.
static constexpr uptr MaxReleasedCachePages = 4U;

uptr CommitBase = 0;
Expand Down Expand Up @@ -725,8 +728,14 @@ MapAllocator<Config>::tryAllocateFromCache(const Options &Options, uptr Size,
uptr EntryHeaderPos;
uptr MaxAllowedFragmentedPages = MaxUnreleasedCachePages;

if (UNLIKELY(useMemoryTagging<Config>(Options)))
if (LIKELY(!useMemoryTagging<Config>(Options))) {
MaxAllowedFragmentedPages += CachedBlock::MaxReleasedCachePages;
} else {
// TODO: Enable MaxReleasedCachePages may result in pages for an entry being
// partially released and it erases the tag of those pages as well. To
// support this feature for MTE, we need to tag those pages again.
DCHECK_EQ(CachedBlock::MaxReleasedCachePages, 0U);
}

Entry = Cache.retrieve(MaxAllowedFragmentedPages, Size, Alignment,
getHeadersSize(), EntryHeaderPos);
Expand Down
Loading