jmb
/
hardened_malloc
mirror of https://github.com/GrapheneOS/hardened_malloc.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

elaborate on the cost of GUARD_SLABS_INTERVAL

pull/103/head
Daniel Micay 2019-08-18 05:42:53 -04:00
parent 7a8c57d0f5
commit d0b466beb8
1 changed files with 8 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
README.md
View File

@ -233,7 +233,14 @@ The following integer configuration options are available:
becomes 1024 for 16 byte allocations with 16kiB as the largest size class, or becomes 1024 for 16 byte allocations with 16kiB as the largest size class, or
8192 with 128kiB as the largest). 8192 with 128kiB as the largest).
* `CONFIG_GUARD_SLABS_INTERVAL`: `1` (default) to control the number of slabs * `CONFIG_GUARD_SLABS_INTERVAL`: `1` (default) to control the number of slabs
before a slab is skipped and left as an unused memory protected guard slab before a slab is skipped and left as an unused memory protected guard slab.
The default of `1` leaves a guard slab between every slab. This feature does
not have a *direct* performance cost, but it makes the address space usage
sparser which can indirectly hurt performance. The kernel also needs to track
a lot more memory mappings, which uses a bit of extra memory and slows down
memory mapping and memory protection changes in the process. The kernel uses
O(log n) algorithms for this and system calls are already fairly slow anyway,
so having many extra mappings doesn't usually add up to a significant cost.
* `CONFIG_GUARD_SIZE_DIVISOR`: `2` (default) to control the maximum size of the * `CONFIG_GUARD_SIZE_DIVISOR`: `2` (default) to control the maximum size of the
guard regions placed on both sides of large memory allocations, relative to guard regions placed on both sides of large memory allocations, relative to
the usable size of the memory allocation the usable size of the memory allocation