mirror of
https://github.com/GrapheneOS/hardened_malloc.git
synced 2024-12-29 17:36:13 -05:00
elaborate on the cost of GUARD_SLABS_INTERVAL
This commit is contained in:
parent
7a8c57d0f5
commit
d0b466beb8
@ -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
|
||||||
|
Loading…
Reference in New Issue
Block a user