回答編集履歴
2
スタックサイズであることを明示
test
CHANGED
|
@@ -22,7 +22,7 @@
|
|
|
22
22
|
|
|
23
23
|
|
|
24
24
|
|
|
25
|
-
* スレッドサイズを大きく、スレッド数を多くしてキャッシュの影響を相対的に小さくする
|
|
25
|
+
* スレッドのスタックサイズを大きく、スレッド数を多くしてキャッシュの影響を相対的に小さくする
|
|
26
26
|
|
|
27
27
|
* [malloc絡みのチューニングパラメータ](https://www.gnu.org/software/libc/manual/html_node/Memory-Allocation-Tunables.html)を調整して、アリーナの確保を抑制する。
|
|
28
28
|
|
1
チューニングパラメータのリンクを追加
test
CHANGED
|
@@ -4,7 +4,7 @@
|
|
|
4
4
|
|
|
5
5
|
1つには、スレッド生成時のスタックの確保が mmap、消滅時の解放が munmap なので増減は確かにあるのですが、glibc の実装としてある程度「一旦確保したスレッド用スタックはキャッシュする」という挙動があるためです。
|
|
6
6
|
|
|
7
|
-
新しい ( 2.34以降?の ) glibc だと、チューニングパラメータ glibc.pthread.stack_cache_size が設けられているのでこの挙動は明らかになってますが、どうやらこのパラメータがない時代から、キャッシュする挙動自体はあるようです。
|
|
7
|
+
新しい ( 2.34以降?の ) glibc だと、チューニングパラメータ [glibc.pthread.stack_cache_size](https://www.gnu.org/software/libc/manual/html_node/POSIX-Thread-Tunables.html) が設けられているのでこの挙動は明らかになってますが、どうやらこのパラメータがない時代から、キャッシュする挙動自体はあるようです。
|
|
8
8
|
|
|
9
9
|
※ Ubuntu18/WSL1(Win10) の glibc 2.27 で確認
|
|
10
10
|
|