maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/compiler-rt/test/scudo/rss.c

58 lines
3.2 KiB
C
Raw Normal View History

[scudo] Soft and hard RSS limit checks Summary: This implements an opportunistic check for the RSS limit. For ASan, this was implemented thanks to a background thread checking the current RSS vs the set limit every 100ms. This was deemed problematic for Scudo due to potential Android concerns (Zygote as pointed out by Aleksey) as well as the general inconvenience of having a permanent background thread. If a limit (soft or hard) is specified, we will attempt to update the RSS limit status (exceeded or not) every 100ms. This is done in an opportunistic way: if we can update it, we do it, if not we return the current status, mostly because we don't need it to be fully consistent (it's done every 100ms anyway). If the limit is exceeded `allocate` will act as if OOM for a soft limit, or just die for a hard limit. We use the `common_flags()`'s `hard_rss_limit_mb` & `soft_rss_limit_mb` for configuration of the limits. Reviewers: alekseyshl Reviewed By: alekseyshl Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D40038 llvm-svn: 318301
2017-11-16 00:40:27 +08:00
// RUN: %clang_scudo %s -o %t
// RUN: %run %t 2>&1 | FileCheck %s --check-prefix=CHECK-nolimit
[scudo] Tuning changes based on feedback from current use Summary: This tunes several of the default parameters used within the allocator: - disable the deallocation type mismatch on Android by default; this was causing too many issues with third party libraries; - change the default `SizeClassMap` to `Dense`, it caches less entries and is way more memory efficient overall; - relax the timing of the RSS checks, 10 times per second was too much, lower it to 4 times (every 250ms), and update the test so that it passes with the new default. Reviewers: eugenis Reviewed By: eugenis Subscribers: srhines, delcypher, #sanitizers, llvm-commits Differential Revision: https://reviews.llvm.org/D57116 llvm-svn: 352057
2019-01-24 23:56:54 +08:00
// RUN: %env_scudo_opts="soft_rss_limit_mb=128" %run %t 2>&1 | FileCheck %s --check-prefix=CHECK-nolimit
// RUN: %env_scudo_opts="hard_rss_limit_mb=128" %run %t 2>&1 | FileCheck %s --check-prefix=CHECK-nolimit
// RUN: %env_scudo_opts="soft_rss_limit_mb=32:allocator_may_return_null=0" not %run %t 2>&1 | FileCheck %s --check-prefix=CHECK-softlimit
// RUN: %env_scudo_opts="soft_rss_limit_mb=32:allocator_may_return_null=1" %run %t 2>&1 | FileCheck %s --check-prefix=CHECK-softlimit-returnnull
// RUN: %env_scudo_opts="soft_rss_limit_mb=32:allocator_may_return_null=0:can_use_proc_maps_statm=0" not %run %t 2>&1 | FileCheck %s --check-prefix=CHECK-softlimit
// RUN: %env_scudo_opts="soft_rss_limit_mb=32:allocator_may_return_null=1:can_use_proc_maps_statm=0" %run %t 2>&1 | FileCheck %s --check-prefix=CHECK-softlimit-returnnull
// RUN: %env_scudo_opts="hard_rss_limit_mb=32:allocator_may_return_null=0" not %run %t 2>&1 | FileCheck %s --check-prefix=CHECK-hardlimit
// RUN: %env_scudo_opts="hard_rss_limit_mb=32:allocator_may_return_null=1" not %run %t 2>&1 | FileCheck %s --check-prefix=CHECK-hardlimit
// RUN: %env_scudo_opts="hard_rss_limit_mb=32:allocator_may_return_null=0:can_use_proc_maps_statm=0" not %run %t 2>&1 | FileCheck %s --check-prefix=CHECK-hardlimit
// RUN: %env_scudo_opts="hard_rss_limit_mb=32:allocator_may_return_null=1:can_use_proc_maps_statm=0" not %run %t 2>&1 | FileCheck %s --check-prefix=CHECK-hardlimit
[scudo] Soft and hard RSS limit checks Summary: This implements an opportunistic check for the RSS limit. For ASan, this was implemented thanks to a background thread checking the current RSS vs the set limit every 100ms. This was deemed problematic for Scudo due to potential Android concerns (Zygote as pointed out by Aleksey) as well as the general inconvenience of having a permanent background thread. If a limit (soft or hard) is specified, we will attempt to update the RSS limit status (exceeded or not) every 100ms. This is done in an opportunistic way: if we can update it, we do it, if not we return the current status, mostly because we don't need it to be fully consistent (it's done every 100ms anyway). If the limit is exceeded `allocate` will act as if OOM for a soft limit, or just die for a hard limit. We use the `common_flags()`'s `hard_rss_limit_mb` & `soft_rss_limit_mb` for configuration of the limits. Reviewers: alekseyshl Reviewed By: alekseyshl Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D40038 llvm-svn: 318301
2017-11-16 00:40:27 +08:00
// Tests that the soft and hard RSS limits work as intended. Without limit or
// with a high limit, the test should pass without any malloc returning NULL or
// the program dying.
// If a limit is specified, it should return some NULL or die depending on
// allocator_may_return_null. This should also work without statm.
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
[scudo] Tuning changes based on feedback from current use Summary: This tunes several of the default parameters used within the allocator: - disable the deallocation type mismatch on Android by default; this was causing too many issues with third party libraries; - change the default `SizeClassMap` to `Dense`, it caches less entries and is way more memory efficient overall; - relax the timing of the RSS checks, 10 times per second was too much, lower it to 4 times (every 250ms), and update the test so that it passes with the new default. Reviewers: eugenis Reviewed By: eugenis Subscribers: srhines, delcypher, #sanitizers, llvm-commits Differential Revision: https://reviews.llvm.org/D57116 llvm-svn: 352057
2019-01-24 23:56:54 +08:00
static const size_t kNumAllocs = 64;
[scudo] Soft and hard RSS limit checks Summary: This implements an opportunistic check for the RSS limit. For ASan, this was implemented thanks to a background thread checking the current RSS vs the set limit every 100ms. This was deemed problematic for Scudo due to potential Android concerns (Zygote as pointed out by Aleksey) as well as the general inconvenience of having a permanent background thread. If a limit (soft or hard) is specified, we will attempt to update the RSS limit status (exceeded or not) every 100ms. This is done in an opportunistic way: if we can update it, we do it, if not we return the current status, mostly because we don't need it to be fully consistent (it's done every 100ms anyway). If the limit is exceeded `allocate` will act as if OOM for a soft limit, or just die for a hard limit. We use the `common_flags()`'s `hard_rss_limit_mb` & `soft_rss_limit_mb` for configuration of the limits. Reviewers: alekseyshl Reviewed By: alekseyshl Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D40038 llvm-svn: 318301
2017-11-16 00:40:27 +08:00
static const size_t kAllocSize = 1 << 20; // 1MB.
static void *allocs[kNumAllocs];
int main(int argc, char *argv[]) {
int returned_null = 0;
for (int i = 0; i < kNumAllocs; i++) {
[scudo] Delay allocations in the RSS check test Summary: D57116 fails on the armv7 bots, which is I assume due to the timing of the RSS check on the platform. While I don't have a platform to test that change on, I assume this would do. The test could be made more reliable by either delaying more the allocations, or allocating more large-chunks, but both those options have a somewhat non negligible impact (more memory used, longer test). Hence me trying to keep the additional sleeping/allocating to a minimum. Reviewers: eugenis, yroux Reviewed By: yroux Subscribers: javed.absar, kristof.beyls, delcypher, #sanitizers, llvm-commits Differential Revision: https://reviews.llvm.org/D57241 llvm-svn: 352220
2019-01-26 01:23:29 +08:00
// sleep for 100ms every 8 allocations, to allow the RSS check to catch up.
if (i != 0 && (i & 0x7) == 0)
[scudo] Tuning changes based on feedback from current use Summary: This tunes several of the default parameters used within the allocator: - disable the deallocation type mismatch on Android by default; this was causing too many issues with third party libraries; - change the default `SizeClassMap` to `Dense`, it caches less entries and is way more memory efficient overall; - relax the timing of the RSS checks, 10 times per second was too much, lower it to 4 times (every 250ms), and update the test so that it passes with the new default. Reviewers: eugenis Reviewed By: eugenis Subscribers: srhines, delcypher, #sanitizers, llvm-commits Differential Revision: https://reviews.llvm.org/D57116 llvm-svn: 352057
2019-01-24 23:56:54 +08:00
usleep(100000);
[scudo] Soft and hard RSS limit checks Summary: This implements an opportunistic check for the RSS limit. For ASan, this was implemented thanks to a background thread checking the current RSS vs the set limit every 100ms. This was deemed problematic for Scudo due to potential Android concerns (Zygote as pointed out by Aleksey) as well as the general inconvenience of having a permanent background thread. If a limit (soft or hard) is specified, we will attempt to update the RSS limit status (exceeded or not) every 100ms. This is done in an opportunistic way: if we can update it, we do it, if not we return the current status, mostly because we don't need it to be fully consistent (it's done every 100ms anyway). If the limit is exceeded `allocate` will act as if OOM for a soft limit, or just die for a hard limit. We use the `common_flags()`'s `hard_rss_limit_mb` & `soft_rss_limit_mb` for configuration of the limits. Reviewers: alekseyshl Reviewed By: alekseyshl Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D40038 llvm-svn: 318301
2017-11-16 00:40:27 +08:00
allocs[i] = malloc(kAllocSize);
if (allocs[i])
memset(allocs[i], 0xff, kAllocSize); // Dirty the pages.
else
returned_null++;
}
for (int i = 0; i < kNumAllocs; i++)
free(allocs[i]);
if (returned_null == 0)
printf("All malloc calls succeeded\n");
else
printf("%d malloc calls returned NULL\n", returned_null);
return 0;
}
// CHECK-nolimit: All malloc calls succeeded
// CHECK-softlimit: soft RSS limit exhausted
// CHECK-softlimit-NOT: malloc calls
// CHECK-softlimit-returnnull: soft RSS limit exhausted
// CHECK-softlimit-returnnull: malloc calls returned NULL
// CHECK-hardlimit: hard RSS limit exhausted
// CHECK-hardlimit-NOT: malloc calls