diff options
| author | Michael Pratt <mpratt@google.com> | 2019-04-03 16:21:38 -0700 |
|---|---|---|
| committer | Shentubot <shentubot@google.com> | 2019-04-03 16:22:43 -0700 |
| commit | 4968dd1341a04e93557bdd9f4b4b83eb508e026d (patch) | |
| tree | 50ef3c28ec24fad937f029f257cbe3338222445f /test | |
| parent | 82529becaee6f5050cb3ebb4aaa7a798357c1cf1 (diff) | |
Cache ThreadGroups in PIDNamespace
If there are thousands of threads, ThreadGroupsAppend becomes very
expensive as it must iterate over all Tasks to find the ThreadGroup
leaders.
Reduce the cost by maintaining a map of ThreadGroups which can be used
to grab them all directly.
The one somewhat visible change is to convert PID namespace init
children zapping to a group-directed SIGKILL, as Linux did in
82058d668465 "signal: Use group_send_sig_info to kill all processes in a
pid namespace".
In a benchmark that creates N threads which sleep for two minutes, we
see approximately this much CPU time in ThreadGroupsAppend:
Before:
1 thread: 0ms
1024 threads: 30ms - 9130ms
4096 threads: 50ms - 2000ms
8192 threads: 18160ms
16384 threads: 17210ms
After:
1 thread: 0ms
1024 threads: 0ms
4096 threads: 0ms
8192 threads: 0ms
16384 threads: 0ms
The profiling is actually extremely noisy (likely due to cache effects),
as some runs show almost no samples at 1024, 4096 threads, but obviously
this does not scale to lots of threads.
PiperOrigin-RevId: 241828039
Change-Id: I17827c90045df4b3c49b3174f3a05bca3026a72c
Diffstat (limited to 'test')
0 files changed, 0 insertions, 0 deletions