Commit Graph

3 Commits

Author SHA1 Message Date
Kostya Kortchinsky a04584b095 [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-25 17:23:29 +00:00
Kostya Kortchinsky f0fbeaf44a [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 15:56:54 +00:00
Kostya Kortchinsky 58f2656d7e [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-15 16:40:27 +00:00