]> git.ipfire.org Git - thirdparty/FORT-validator.git/commitdiff
FIX: tunned -> tuned 33/head
authorximon18 <3304436+ximon18@users.noreply.github.com>
Wed, 20 May 2020 12:51:57 +0000 (14:51 +0200)
committerGitHub <noreply@github.com>
Wed, 20 May 2020 12:51:57 +0000 (14:51 +0200)
docs/run.md

index a56aec121cb5be0a8660e8dc28ba0dc8dc564bd9..095e9a37569d4deb425bc6e910251129aaaf1500 100644 (file)
@@ -96,7 +96,7 @@ Once a memory block is released using `free`, there's no warranty that such memo
 
 Most of FORT Validator allocations are temporary since they're needed at the validation cycles, this causes a logarithmic growth on the program memory usage. Only a part of that memory is really allocated, the other part consist of free space that hasn't been returned to the OS yet.
 
-glibc has the _[Tunables](https://www.gnu.org/software/libc/manual/html_node/Tunables.html)_ feature. One of the things that can be tunned is precisely the maximum number of "arenas" that the program will use. There are many other things that can be tunned, but they are out of scope of this document.
+glibc has the _[Tunables](https://www.gnu.org/software/libc/manual/html_node/Tunables.html)_ feature. One of the things that can be tuned is precisely the maximum number of "arenas" that the program will use. There are many other things that can be tuned, but they are out of scope of this document.
 
 Basically, limiting the number of arenas helps to avoid the memory growth. This can be achieved by setting the environment variable `MALLOC_ARENA_MAX`, please read more at [Memory Allocation Tunables](https://www.gnu.org/software/libc/manual/html_node/Memory-Allocation-Tunables.html#index-glibc_002emalloc_002earena_005fmax).